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Foreword 


d Es 
TECHNICAL REVIEW present some new ideas and techniques relating to the 
combination of circuit and message switching systema. By a circuit switching 
system we mean one in which a terminal is connected directly to another ter- 
tal for the purpose of handling traffic. A message switching system is one 
which a message is transmitted into some form of storage, where it is held 
until а connection can be established to the destination point for the delivery 
of the message. 

To some of our readers it may appear that the problems for which solu- 
tions are proposed should have been resolved long ago. However, it may be well 
to review the generis of some of the arte of circuit and message switching. The 
firat eireuit. switching “system” probably appeored in the сату days of the 

lephowe, when it was recognized that some system of interconnecting sub- 
aseribers, even in a very small “exchange,” was necessary. Early systema used 
simple combinations of switches to make these interconnections; following th 
Jacks, connected by plug cords, were used, Aa the industry progressed connec- 
tions were по longer made by simple cords, instead “trunking” was used be- 
tween ewitchboards to permit increasing numbers of subscribers to be handled. 

It ia well to point out that cirewit wwitehing by machines, rather than by 
Auman operators, сате into use in the telephone industry around 1900. It pro- 
vided theoretical advances which were not entirely attained because their ad- 
vantages could not be realized by the mechanical and electrical equipment then 
available. 


The early telegraph industry was the first in the communications field 
to use the technique of message store and forward systems, Telegraph circuits. 
did not permit and were not capable, in those days, of reaching from one loca- 
tion to many locations in the country. As a result Morse operators, operating 
the more important trunk circuits, would send a message from destination A 
to destination B, where it was hand copied, stored in the form of а written 
message on а blank, and delivered to another operator who would forward it 
from destination B to destination C. 

Until the early 30's circuit switching had little application in the tele- 
graph industry but was primarily confined to the telephone systems. Message 
witching systems have been principally the province of the telegraph industry, 
‘and various forms of it have been used for some 40 or 60 years. 

It may be surprising that only within the last decade or во have we seen 
these two well established basic types of switching ryrtems brought together 
to perform functions that neither сам do as well operating separately. 
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disciplines can. 
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very 
‘changes were made. This signicant improvement 
im message processing was achieved without degrading performance in the circuit switching 
network, 

Finally, in the fourth article an ott-line computer tool, NETSIM-- NETwork SiMulation, 
was developed which permits one to conveniently determine “End-to-End Grade of Service 


‘Through Circuit Switching Network Simulation” Its usefulness ties in the ability to determine 
variation of service factors in the individual 


SPECIAL AR.S. ISSUE JUNE 1969 
WESTERN UNION TECHNICAL REVIEW VOL. 23, NO. 3 


Readership Survey 
One of the two cards below, should be returned to the Editor, before July 1, 1969: 
Card #1 for Western Union Employees who read the Technical Review 
Card #2 for Outside subscribers who receive the TECHNICAL REVIEW regularly 


Mary C. Kililea, Editor 
120169 


To: Westem Union Readers of the TECHNICAL REVIEW 


É Fram: The Editor of the TECHNICAL REVIEW sim 
t Please answer the questions below, and retum this card for our Readership Survey. 
| Check one box, yes or no. Yes Мо 
1. Do you tke the new Format of the TECHNICAL REVIEW? о о 
2. Do you have а binder for the TECHNICAL REVIEW? n B 
| 3. Do you find the TECHNICAL REVIEW more interesting since Jan. 19687 O О 
t 4. Do you read more than 2 articles in any issue? n n 
5. What was the t of the most interesting article since Jan, 19687 
6 i the technical content of the TECHNICAL REVIEW 
9 atthe right ewe? D D 
orb) at too high a level? O о 
од  m*ebwske? O O 


To: Outside subscribers to the TECHNICAL REVIEW 
From: The Editor of the TECHNICAL REVIEW se 


Please answer the questions below and return this card, with your address label on this. 
Issue, for our Readership Survey. 


Yes No 


1) is your address on the address label correct? HB 
If not, indicate a correct 4line address, below 


2) To how many persons, other than yourself, do you route this publication? 
3) What is your area of interest? 


4) What was the titie of the article which interested you most since the Winter (January) 
1968 issue? 


CONTENTS 

Service Improvement through MSC Program Control 
Improved Trunk Allocation in a Congested Network 
Thruput Improvement in Message Switched Traffic 


End to End Grade of Service through 
Circuit Switching Network Simulation 


Authors 


Abstracts 


Copyright © 1969 The Western Union Telegraph Company, All Rights 
Reserved 


114 


126 


128 


Republication: All rights of republication, including translation into foreign 
languages, are reserved by the Western Union Technical Review. Requests 
for republication and translation privileges should be addressed to THE 
EDITOR of Technical Review, Western Union, Mahwah, N.J. 


in Spring, Summer, Autumn and 
Winter. 


SERVICE IMPROVEMENT 
THROUGH MSC 
PROGRAM CONTROL 


J. С. PARR 
and 


The circuit switching network is a commonly accepted method of providing com- 
munication services to subscribers whose individual needs do not justify dedi 
cated communication facilities and equipment. The economic advantage to these 
subscribers is they can satisfy their communications needs by sharing a limited 
amount of common control equipment and facilities. In a circuit switching net 
work subscribers obtain communications service by bidding for the common 
control equipment and facilities. In the conventional circuit switching network 
this competition is usually not detrimental but in a unique system such as ARS, 
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where autom: 
‘service, speci 


ic message switches are competing with teleprinter stations for 
steps must be taken to insure that the service provided to all 


Subscribers is consistent with their communications requirements. 


The Advanced Record System is a hybrid tele 
communication system consisting of a Circuit 
Switching Network (CSN) and three dispersed 
Message Switching Centers (MSCs). The CSN is 
the backbone of the system in the sense that it 
provides the basic ARS service, i.e., it provides, on 
dialing, point-to-point connections, by direct or 
alternate routes, for real time exchange of com 
munications traffic or data between ARS sub. 
scribers. The MSCs enhance the system capability 
by providing additional services to the subscribers 
beyond the capability of the CSN. These additional 
services include store and forward handling, data 
collection and distribution, message exchange, and 
multiple address handling. Subscribers request 


these special services by transmitting appropri- 
ately formated messages through the CSN to the 
MSCs. The MSCs provide these services by рег 
forming the required processing and transmitting 
messages through the CSN to the appropriate 
subscribers. In effect, the MSCs are in competition 
with the subscribers for the available common 
control equipment and facilities in the CSN. 

This competition is not, in itself, undesirable or 
detrimental to system performance. However, an 
‘examination of system operation and performance, 
several months after cutover of the initial phase, 
revealed two basic facts. First, a considerable 
amount of network congestion and an inordinate 
number of incompleted calls resulted from the 


Figure 1—Network Diagram of ARS 


‘competition for common control equipment and 
facilities. Second, the MSCs were prime contrib- 
tors to the network congestion. 


The Problem of System Configuration 

The network diagram of ARS, shown in Figure 1, 
indicates that the MSCs have privileged access to 
the CSN. Traffic from an MSC enters the CSN 
through its collocated Junction Office (JO). Traffic 
from a subscriber enters the CSN through the sub- 
scriber's District Office (DO). The impact on sys- 
tem performance due to this privileged access 
given to the MSCs can be demonstrated by com- 
paring CSN operation for subscriber originated 
traffic and for MSC originated traffic. 


А Subscriber Call 

A subscriber-to-subscriber call proceeds through 
the originating subscriber's DO, through one of 
the JOs and finally through the called subscriber's 
DO. The use of the registers in the DOs and the 
JO in this procedure is of particular significance. 
The register is a unit of common control equip- 
ment found in both DOs and JOs. One of its 


functions is to accept, store and forward the dial 
digits supplied by the calling subscriber. In a sub- 
scriber-to-subscriber call, the calling subscriber 
sends a service request signal to the associated 
DO. The DO recognizes the service request by 
attaching one of its registers to the subscriber's 
line and signalling back over the subscriber's line. 
The subscriber responds by sending the five dial 
digits to the DO where they are stored in the DO 
register. The DO analyzes the dial digits to dete 
mine the required destination, seizes an appropri- 
ate outgoing trunk to a JO and determines a path 
through the DO matrix. The JO responds to the 
trunk seizure at the DO by attaching one of its 
registers to the seized trunk and signalling back 
over the trunk to the DO. The DO responds by 
sending the five dial digits in the DO register to 
the JO where they are stored in the JO register. 
The first two dial digits uniquely identify the 
destination DO and are used by the JO to set up 
the necessary circuit. The JO analyzes the dial 
digits, seizes an appropriate outgoing trunk to 
the destination DO and determines a path through 
the JO matrix. The destination DO responds to the 
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trunk seizure at the JO by attaching one of its 
registers to the seized trunk and signalling back 
over the trunk to the JO. The JO then completes 
the path between the originating DO register and 
the destination DO register, releases the JO reg. 
ister for use in setting up other calls and sig- 
nals the originating DO. The originating DO 
sends the five dial digits to the destination DO 
where they are stored in the DO register. The 
destination DO analyzes the dial digits to deter: 
mine the required subscriber, seizes the circuit 
to that subscriber, determines a path through the 
DO matrix and signals the originating DO. At this. 
Point the end-to-end connection has been made 
and the originating DO sends a "Who Are You" 
signal to the destination DO. If the answerback 
inating DO is valid, both DOs 
ir registers. In a typical subscriber-to- 


an average of five seconds and the JO register 
will be in use for approximately two seconds. 


‘An MSC Call 


Register usage is somewhat different in an 
MSC-to-subscriber call. The MSC requests service 
by seizing one of its output trunks to the col- 
located JO. The JO recognizes the service request 
by sending a "trunk seized" signal to the MSC. 
After connecting one of its registers to the seized 
trunk, the JO sends a "register attached" signal 
to the MSC. The MSC responds by sending the 
five dial digits to the JO where they are stored 
in the JO register. The JO analyzes the dial digits 
to determine the required destination DO, seizes 
an appropriate outgoing trunk to the destination 
DO and determines a path through the JO matrix. 
The destination DO responds to the trunk seizure 
at the JO by attaching one of the DO registers to 
the seized trunk and signalling back over the trunk 
to the JO. The JO then sends the five dial digits 
to the destination DO where they are stored in the 
DO register. The DO analyzes the dial digits to 
determine the required subscriber; it then seizes 
the circuit to that subscriber, determines a path 
through the DO matrix and signals back to the JO. 
At this point the end-to-end connection has been 
made and the registers in the JO and DO can be 
released. For this type of call the JO register is 
required to perform all JO register functions re- 
quired in a subscriber-to-subscriber call and also 
to perform the function of a DO register since 


there is no originating DO. In a typical MSC-to- 
subscriber call the registers in the DO and the 
JO will each be in use for approximately five 
seconds. 


The critical difference between the two types of 
calls is the amount of time the JO register is in 
use, In а subscriber-to-subscriber call the JO reg- 
ister is in use for approximately two seconds. In 
an MSC-to-subscriber call the JO register is in use 
for approximately five seconds. Since more than 
half the traffic handled by ARS flows through the 
MSCs, this difference in JO register usage is sig- 
nificant. It indicates that the operation of the 
interface between the MSC and the JO is a poten- 
tial area for improving CSN performance, at least 
in terms of register usage. 


Problem of Program Control 


Two basic programs are used by the MSC to 
deliver a message in storage in the MSC to the 
ARS subscriber. The first program, Precedence 
‘Message Selection (PMS), periodically reviews the 
messages in storage and determines whether any 
messages require delivery to the CSN. If а mes- 
sage requiring a CSN delivery is found, it is given 
to the second program, Initiate Call (INC), which 
controls the exchange of signals and message 
data with the CSN and causes the message de- 
livery to take place. А review of these two programs 
Performed prior to the addition of the MSC pro- 
gramming changes described in this article, indi- 
cated that the only criterion for selection and 
delivery of a message to the CSN was MSC output 
trunk availability. If a message in storage required 
delivery to the CSN and an output trunk from the 
MSC to the CSN was available, the MSC would 
select this message and attempt to deliver it re- 
gardless of the CSN traffic load. 


The inefficient operation which can result when 
the MSC to CSN interface is controlled only by 
MSC to CSN trunk availability can be demonstrated 
using the simplified network diagram shown in 
Figure 2. This network diagram was generated by 
taking part of the ARS network and scaling down 
the number of registers and trunks. Special care 
was taken in scaling down the network in order to 
insure that conclusions reached in examining the 
scaled down network also apply completely in the 
actual network. Three cases can be examined, 
using the simplified network diagram, which will 
demonstrate the problem of MSC program control. 


presens 


1) Register Usay 

The first case involves register usage. Suppose 
that the MSC schedules six calls to the DO and 
that at the same time the DO receives two servi 
requests from its subscribers for calls to the MSC. 
The three registers in the JO are attached to three 
of the six MSC to JO trunks requesting service. 
The two registers in the DO are attached to the 
two subscriber lines. The JO and the DO begin 
seizing trunks to each other and determining 
matrix paths. The worst condition occurs when the 
DO is successful in seizing two trunks to the JO 
collocated with the MSC. In this case all JO to DO 
trunks are seized, with two JO to JO trunks seized 
as alternate routes. Neither the JO nor the DO can 
honor any incoming trunk seizures by attaching 
registers since all registers are acting as originat- 
ing registers. This is an unfortunate communica- 
tions standoff and none of the five calls can be 
extended until one of the registers times out and 
releases. The JO register releases in twelve sec- 
onds and the DO register releases after eight 
seconds. Whether the MSC calls will be extended 
to the DO, depends on the other outstanding re- 
quests for registers at the DO. It is also interesting 


to note that three MSC originated calls are waiting 
for JO registers and may prevent DO originated 
calls from receiving register service. Two conclu- 
sions may be drawn from this case. First, no calls 
are completed through the JO or the DO for eight 
seconds. Second, if one of the five registers had 
been available, all calls might have been completed, 


2) Trunk Usage 


The second case involves the use of JO to DO 
trunks. Suppose that two of the three prime JO 
to DO trunks are occupied with subscriber-to-sub: 
scriber calls, that all registers are available and 
that the MSC schedules six calls to the DO. Three 
of these calls cause the JO to attach registers. 
Two of these three calls are serviced by the two 
DO registers. When one of these two calls is ex- 
tended to the subscriber and the DO register re- 
leased, the third call is serviced by the DO register. 
Ultimately all registers are released. However, 
there are still three outstanding MSC originated 
calis awaiting service in the JO and all JO to DO 
trunks are occupied. The JO honors the three out- 
standing MSC originated calls by attaching reg- 
isters. Since all trunks to the DO are occupied, 
the JO must route the calis to the next JO. Only 
two of these outstanding calls can be alternately 
routed since only two trunks are available to the 
next JO. The collocated JO responds to the third 
outstanding call by sending a "busy trunk” signal 
to the MSC which causes the MSC to abort the 
call. The second JO responds to the two alternate 
routed calls with "busy trunk" signals since all 
trunks from the second JO to the DO are occupied. 
These signals are returned to the MSC which 
Causes the MSC to abort these two calls also. 
Therefore, of the six MSC calls, three are com- 
pleted and three are terminated in busy trunk con- 
ditions. Again two conclusions can be drawn. First, 
the MSC not only scheduled its traffic without re- 
gard for the existing CSN traffic but actually 
Scheduled more traffic than the CSN was physi 
cally equipped to handle. Second, the aborted calls 
used common control equipment and facilities 
which might have been needed to handle other 
call 


3) Subscriber Equipment Usage 

The third case involves the use of subscriber 
equipment. Suppose that the simplified network 
is not handling any traffic and that the MSC 
schedules six calls to the DO. Further assume that 


all six calls are destined to the same subscriber 
and that this subscriber has only one teleprinter. 
In this case five of the six calls reach the DO. 
The sixth call is extended to the second JO and 
then aborted due to а busy trunk condition. One 
of the five calls reaching the DO is completed to 
the subscriber and the remaining four calls are 
aborted due to а busy station condition. 

Since more than half of the large number of 
busy station conditions encountered by the MSC 
‘occur because of MSC traffic to the station, the 
inefficient use of common control equipment and 
facilities resulting from this aspect of MSC traffic 
scheduling is significant. 


New MSC to CSN Interface Criteria 

The three cases cited above indicated that three 
basic changes were necessary in the MSC pro- 
grams, which control the selection and scheduling 
of traffic from the MSC to the CSN. 

a) The number of JO registers in use simultan- 
eously for MSC traffic should 
some reasonable share of the available reg- 
isters. 

b) The number of simultaneous calls to a DO 
by the MSC should be limited such that the 

MSC traffic does not occupy more than its 

fair share of the JO to DO trunks. 

The number of simultaneous calls to an in 

ividual subscriber by the MSC should be 

limite at the MSC traffic does not 
'exceed the number of pieces of subscriber 
equipment and, in the case of subscribers 
with more than one piece of equipment, does 
mot occupy more than its fair share of the 
subscriber's equipment 

The exact nature of the program changes and 

the system considerations involved in imposing 
these limitations can best be understood by exam- 
ining the manner in which the MSC program 
caused a delivery to be made to the CSN. 


Original Rules of Interplay 

Prior to the inclusion of the MSC programming 
changes described in this article, the rules of inter- 
play between MSC and CSN were as follows. When 
the MSC decided that a message was to be de- 
livered to the CSN and that a trunk to the JO was 
available, the output area associated with the se- 
lected trunk was “initialized with all data neces- 
sary to make the delivery and control was given 
to the Initiate Call (INC) program. This program 
controls the exchange of signals with the CSN in 
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order to obtain the desired end-to-end connection 
with the subscriber, verifies the identity of the 
connected subscriber, transmits the message and 
finally terminates the connection after again veri- 
fying the identity of the subscriber. The interval 
between the time at which INC is given control 
and the time at which message transmission be- 
gins is called pre-message interplay. Interplay is 
of particular significance since the majority of the 
controls necessary to implement the criteria cited 
above had to be implemented in interplay. 

To begin interplay, the INC program seized the 
trunk to the JO and began a 500 millisecond time. 
‘out waiting for a "trunk seized” signal from the 
JO. If the “trunk seized” signal was received be- 
fore the expiration of the timer, INC stopped the 
timer and started a second timer of twelve seconds 
waiting for a “register attached” signal from the 
JO. If either timer expired before the expected 
signal was received from the JO, the seized trunk 
was released and interplay was restarted over 
another trunk or if no other trunk was available, 
over the same trunk. 

When the "register attached" signal was re- 
ceived from the JO, INC stopped the twelve second 
timer, transmitted the five dial digits to the JO 
and started a fifteen second timer waiting for con- 
nection status digits from the JO. The connection 
its can specify any one of four condi- 
: station connected, station busy, trunk busy 
ог deranged. If the "station connected" signal was 
received, INC sent a "who are you" signal and 
verified the answerback received from the con- 
nected station. If the answerback was correct, pre- 
message interplay was complete and message 
transmission began. If the answerback was incor- 
rect, the error path was similar to that taken when 
the connection status digits specified a conditi 
other than station connected or when no connec- 
tion status characters were received and the fif- 
teen second timer had expired. 

Five functions were performed in this error path. 
A printout was made on the MSC high speed line 
printer specified the time of the error, the 
message number, the dial digits, a unique code 
indicating the type of error, the connection status 
digits received, and the trunk number. An error 
journal was also made on magnetic tape and con- 
tained the same basic information. A disconnect 
signal was sent over the trunk to the CSN. The 
aborted message delivery was entered in the busy 
table which automatically delayed the next at- 


tempt to deliver the message for 60 seconds. 
Finally, the output area was released. The only 
exception in this error handling was the processing 
of a "Z" or flash precedence message. In this case 
the message delivery was not placed in the busy 
table and the output area was not released. In- 
stead, interplay was restarted on another trunk 
or on the same trunk if no other trunk is available. 


Necessary Programming Changes 

Two programming changes had to be made in 
the MSC program to implement the three criteria 
cited above. The first change, Register Usage 
Control, limits the MSCs share of the JO registers 
and prevents the communications standoff that can 
‘occur when the MSC seizes all JO registers. The 
second change, Trunk and Subscriber Equipment 
Usage Control, limits the MSCs share of the JO 
to DO trunks and its share of the subscriber's 
equipment. This change, in effect, permits the 
MSC to attempt only those deliveries have a 
high probability of successful completion. Those 
deliveries with a low probability of successful com- 
pletion are sent directly to the busy table without 
incurring the associated unnecessary use of CSN 
common control equipment and facilities. 

Both changes made in the MSC program will be 
discussed from two points of view. First, the tables 
and data necessary to provide the required control 
will be described. Then the control logic and the 
manner in which it was incorporated as part of the 
improved design in the MSC program will be 
defined. 


Register Usage Control 

Program control of register usage by the MSC 
depends on the three word Register Table added 
а5 part of the design improvement to the MSC 
program. The first word is the current registers-in- 
use counter and contains the actual number of 
registers currently in use. The second word con- 
tains a number specifying the maximum number 
of registers which can be used by the MSC during 
peak hour operation. The third word contains a 
number specifying the maximum number of regis- 
ters which can be used by the MSC during non- 
peak hour operation. Two values are necessary 
since there is a substantial difference between peak 
hour and non-peak hour CSN originated traffic. 

When the Precedence Message Selection (PMS) 
program finds a message delivery for the CSN, it 
makes two checks before scheduling INC. First, 
it checks the precedence level of the message. 


If the message is a “Z” or flash precedence mes- 
sage, INC is scheduled regardless of register 
usage. If the message is not a flash message, 
PMS checks register usage. If the registers-in-use 
counter is less than the maximum permitted, INC 
is scheduled to deliver the message. If the regis- 
ter-in-use counter is not less than the maximum 
permitted, PMS will not schedule the message de- 
livery to the CSN on this selection cycle. 

The maximum value selected for comparison 
with the register-in-use counter is done by the 
program in conjunction with a console skip switch 
which is under the control of the MSC operator. If 
the skip switch is in the normal position, the peak 
hour maximum value will be used. If the skip 
switch is in the set position, the non-peak hour 
maximum value will be used. The programming 
change is designed such that the program auto- 
‘matically adjusts whenever the console skip switch 
setting is changed. 

The registers-in-use counter is modified at five 
points in the program. It is incremented by one 
whenever a “register attached” signal is received 
from the CSN. It is decremented by one whenever 
connection status digits have been received from 
the CSN and whenever the MSC timer expires 
before connection status digits have been received. 
It is also incremented and decremented as part 
of the trunk and subscriber equipment usage con- 
trol described below. 

This programming change eliminates the regis- 
ter problem cited earlier. With the appropriate 
choice of a peak hour maximum value, the MSC 
will not be permitted to seize all JO registers si- 
multaneously. Consequently, the communication 
standoff which can result when the MSC seizes 
all JO registers cannot occur. 


Trunk and Subscriber Equipment Usage Control 
Program control of JO to DO trunk usage by the 
MSC depends on the District Office Table (DOTAB). 
DOTAB contains twenty four entries, one for each 
DO in ARS. Each entry contains two words. The 
first word contains the first two dial digits which 
uniquely identify the DO and a trunks-in-use counter. 
which specifies the number of deliveries in prog- 
ress (and therefore the number of trunks in use) 
to the DO. The second word contains two maximum 


Program control of subscriber equipment usage 
by the MSC depends on the Multiple Equipment 


Table (XTAB) and on the Current Connections 
Table (DCTAB). XTAB is basically a table of those 
subscribers who have more than one piece of 
equipment. It contains 200 three-word entries 
which is sufficient to permit all multi-equipped 
subscribers to be included and to provide sufficient 
room for system growth. The first two words of the 
XTAB entry contain the five dial digits which 
uniquely identify the subscriber and а subscriber 
‘equipment-in-use counter which specifies the num- 
ber of deliveries in progress (and therefore the 
number of pieces of equipment in use) to the 
subscriber. The third word contains two maximum 
values; one for peak hour operation and one for 
поп-реак hour operation. ОСТАВ is a table con- 
taining 16 two-word entries and is used to record 
the five dial digits of the subscribers currently 
receiving traffic from the MSC. Its size is sufficient 
to contain an entry for each output trunk. 


Modified Interplay 
The three tables are used by the INC program 
ter the PMS program has selected а CSN mes- 
sage delivery, verified that a register can be re- 
quested, assigned an available trunk to this de- 
livery, “initialized” the output area associated with 
the trunk and scheduled INC. Before seizing the 
output trunk and starting interplay, INC must per- 
form a number of checks. First, the message 
precedence is checked. If the message is a “Z” or 
flash precedence message, INC immediately be- 
gins interplay by seizing the output trunk to the 
CSN. If the message is not a flash message, then 
the tables must be used to check the delivery. The 
first two dial digits stored in the output area are 
used to search the DOTAB to find the appropriate 
entry. When the appropriate DOTAB entry has 
been found, the number of calls in progress to the 
DO, as specified by the trunks-in-use counter (the 
first word of the entry) is compared to the maxi- 
mum number permitted (the second word of the 
entry). If the number of calls in progress is less 
than the maximum number permitted, the trunks- 
in-use counter is incremented by one and a sub- 
scriber check is made. If the number of calls in 
progress is greater than or equal to the maximum 
number permitted, interplay will not be attempted 
for this delivery and a special error path must be 
taken since a simulated busy trunk (a busy trunk 
without interplay) has occurred. 
If a trunk is available, all five dial digits are 
used to search XTAB to determine if the subscriber 


has more than one piece of equipment. If the sub- 
scriber is found in the table, the number of calls 
in progress to the subscriber as specified by the 
subscriber equipment-in-use counter (second word 
of the entry), is compared to the maximum num- 
ber permitted (the third word of the entry). If the 
number of calls in progress to the subscriber is 
less than the maximum number permitted, the 
subscriber equipment-in-use counter is incre- 
mented by one, the five dial digits are placed in an 
available entry in DCTAB and INC begins interplay 
by seizing the output trunk to the CSN. If the num- 
ber of calls in progress to the subscriber is not less 
than the maximum number permitted, interplay will 
not be attempted for this delivery, the trunks-in-use. 
counter in the DOTAB entry is decremented by one 
and а special error path must be taken since а 
simulated busy station (а busy station without 
interplay) has occurred. The trunks-in-use counter 
in the DOTAB entry is decremented by one be- 
cause a simulated busy station error condition 
has occurred and no DO trunks will be used for 
this call 

If the subscriber is not found in XTAB, the five 
dial digits are compared to the dial digits in the 
entries in DCTAB. If no active entry with 
identical dial digits is found in DCTAB, the five 
dial digits are placed in an available entry in DCTAB 
and INC begins interplay by seizing the output 
trunk to the CSN. If an active entry with dial digits 
identical to those being checked is found in ОСТАВ, 
interplay will not be attempted for this delivery, 
the trunks-in-use counter in the DOTAB entry is 
decremented by one and the simulated busy sta- 
tion error path must be taken. 

In checking the DOTAB or XTAB entry, the se- 
lection of the maximum value for comparison with 
the trunks-in-use counter or the subscriber equip- 
mentin-use counter is done by the program in 
conjunction with the same console skip switch 
which controls the maximum register value chosen. 
If the skip switch is in the normal position, the 
peak hour maximum values will be used. If the 
skip switch is in the set position, the non-peak 
hour maximum values will be used. As is the case 
with the maximum register values, the program- 
ming change is designed to adjust automati- 
cally whenever the console skip switch setting 
is changed. 

А message can terminate normally at the end 
of message, prematurely due to an error encoun- 
tered in interplay or in message transmission or 


prematurely due to preemption by а "2" message. 
Whenever a message terminates, the various tables 
are updated. The current trunks-in-use counter in 
the appropriate DOTAB entry and the subscriber 
‘equipment-in-use counter in the appropriate XTAB 
entry are decremented and the entry in DCTAB 
is removed. 


Simulated Error Path 

The special error path taken for the simulated 
busy conditions is analagous to the normal error 
path used for interplay errors with two basic ex 
ceptions. The error mnemonic is different and the 
trunk is not disconnected since it was never 
seized. A printout of a trunk busy condition en- 
countered in interplay contains an identifying 
mnemonic OBZT (Output Busy Trunk). A busy 
station error printout due to an interplay error 
contains the mnemonic OBZS (Output Busy Sta- 
tion). The error mnemonics for the pseudo busy 
conditions encountered in checking the control 
tables are, respectively, SBZT, (Simulated Busy 
Trunk) and 5825 (Simulated Busy Station). These 
printouts indicate to the MSC operator that the 
ciated delivery has been placed in the busy 
table by program decision and no attempt has 
been made to make the delivery to the CSN. 

The average time spent in interplay is approxi- 
mately five seconds. This time is even higher if 
only those calls which encounter interplay errors 
are considered. The decision to take the simu- 
lated busy error path is made in a matter of micro- 
seconds. In order to give the subscriber the full 
benefit of the equipment and facility usage saved 
by these program controls, the simulated busy 
error path is not entered for seven seconds after 
the simulated busy condition is discovered. This 
holds the output area associated with this trunk 
or seven seconds and prevents the MSC from 
processing another delivery using this output area 
ог its associated trunk. In addition, the registers- 
in-use counter is incremented by one when the 
‘simulated busy condition is discovered and decre- 
mented by one, seven seconds later, when the 
simulated error path is taken. This, in effect, gives 
the register usage saved by taking the simulated 
error path to the subscriber rather than the MSC. 
Neither one of these special provisions alters MSC 
operation over what it was prior to these program 
changes. They simply insure that the efficiency in 
the use of common control equipment and facili- 
ties is reflected in improved performance for 
subscribers. 


The trunk and subscriber equipment control 
programming change eliminates two problems. 
First, with the appropriate choice of the peak hour 
maximum value, the MSC is limited to its fair 
share of the JO to DO trunks and can no longer 
schedule more traffic to a DO than the CSN is 
equipped to handle. This eliminates the trunk 
problem cited earlier. Second, the MSC cannot 
attempt to transmit more than one message at a 
time to subscribers with one piece of equipment. 
This eliminates the subscriber equipment problem 
cited earlier. 


Choice of Limits 
One of the most difficult aspects of limiting 
the MSCs share of common control equipment and 


limits. The non-peak hour limits are straight- 
forward. They are equivalent to the maximum 


equipment and facilities available in the CSN. 
The peak hour limits, however, must be examined 
on an individual basis. 

In the case of registers, the peak hour values 
chosen for the Romney, Berwick and Mount Aukum 
MSCs were respectively four (of six), four (of 
six), and three (of four). Performance data indi- 
cated that these limits, while conservative, would 
provide significant CSN service improvement at 
little expense in MSC thruput or performance. 

In the case of trunks the peak hour values were. 
chosen equivalent to the number of direct trunks 
from the JO collocated with the MSC to the DO 
in question. This rule does not cover all cases 
since the JOs in Romney and Mount Aukum are 
not connected to all DOs. This is simply a re- 
flection of CSN connectivity rules under which 
each DO is connected to two of the three JOs. 
In this case the peak hour trunk value was chosen 
equivalent to the smaller of the peak hour trunk 
values in those MSCs whose collocated JO is di- 
rectly connected to the DO. This choice was based 
оп the rationale that the MSC without direct con- 
nection via its collocated JO, would only transmit 
is DO in the event that one of the 
was off-line and in 
this case can be permitted to use a number of 
trunks equivalent to the smaller of the two peak 
hour values used at the other MSCs. Performance 
data again indicated that these limits, while also 
conservative, would provide a significant service 
provement at little expense in the MSC thruput 
or performance. 


It should be noted that the choice of peak hour 
values equivalent to the number of direct trunks 
does not mean that an MSC call cannot take an 
alternate route. The decision to take the direct 
route or an alternate route is strictly under the 
control of the JO. 

In the case of subscriber equipment the peak 
hour maximum values were chosen identical to 
the non-peak hour maximum values. This was 
because information on subscriber traffic charac- 
teristics was not available, Even here service im- 
provement would occur since, prior to this change, 
the MSC calls to a subscriber were limited only 
by the number of output trunks to the CSN. 


Operator Control. 

Two console skip switches are programmed into 
these program modifications in order to permit 
operator intervention. One console skip switch 
permits the operator to select either of two equip- 
ment values as the maximum value available for 
MSC use. If this skip switch is in the normal 
position, the MSC will be limited to the peak hour 
maximum value of registers, JO to DO trunks and 
subscriber equipment. If this skip switch is in the 
set position, the MSC will be limited to the non 
peak hour maximum equipment values which in 
effect permits the MSC to use all CSN equipment. 
This ability is particularly useful when the MSC 
reads in high speed tapes during non-peak hours 
and distributes the messages on these tapes to 
various subscribers. 

‘The second console skip switch controls the 
SBZT and SBZS printouts. If this skip switch 
in the normal position, the SBZT and SBZS print- 
‘outs will occur on the line printer whenever the 
simulated error path is taken. If this skip switch 
is in the set position, the SBZT and SBZS printouts 
will be eliminated. All other functions including 
error journalling will still take place and no other 
printouts will be affected. This flexibility is added 
because in certain cases the number of SBZS and 
SBZT printouts can become quite large and the 
printouts do not reflect true CSN activity since 
the calls are not being attempted. 


Performance Improvement 

А number of valid methods can be used to сот 
pare performance before and after the program- 
ming modifications described above. One method 
is to analyze the journals created during the on- 
line operation of the MSCs before and after the 
programming changes. Table 1 is а synopsis of 
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the data obtained by running the IOSTAT and 
BZSTAT programs, two off-line journal processing 
programs. IOSTAT supplies the actual message 
data and the actual error data while BZSTAT sup- 
plies the actual error data and the simulated error 
data. All data shown in the columns labeled BE- 
FORE is a straight averaging of data derived from 
journals for the period from March 6 to March 10, 
1967 and from March 13 to March 17, 1967, а 
period of two calendar weeks prior to the imple: 
mentation of these programming changes. The 
data shown under the columns labeled AFTER 
is a straight averaging of data derived from jour- 
nals for the period from January 15 to January 
19, 1968 and from January 22 to January 26, 
1968, again a period of two calendar weeks, fol- 
lowing the implementation of these programming 
changes. 


Results of Program Changes 

The data in Table 1 indicates that MSC thruput 
has increased significantly in every case and in 
most cases the increase is more than fifty percent. 
The data also indicates that the real busy trunk 
and real busy station error conditions decreased 
significantly in all cases and in all but one case 
the decrease was more than fifty percent, How- 
ever, this data ony indicates that MSC operation 
was more efficient. The real question is whether 
ог not this MSC efficiency was reflected in а CSN 
service improvement. The data on simulated busy 
station and simulated busy trunk errors indicates 
that a considerable amount of register usage time 
was released for use by ARS subscribers. Based 
‘on an average use of five seconds, the average 
daily register time released for use by the Berwick 
JO was 3.7 hours. 

Another method of estimating system perform. 
ance is to compare the number of JO ге 
seizures for incompleted calls to the number of 
JO register seizures for completed calls. Prior to 
the programming modifications this ratio was 1.6 
to 1.0. Following the programming modifications 
the ratio was 0.6 to 1.0. To be specific the Berwick 
30 required, on the average, 14,630 register sei- 
zures per day to handle its traffic during the two 
week period in March cited in Table 1 and re- 
quired, on the average, 10,709 register seizures 
per day to handle the traffic during the two week 
period in January cited in Table 1. 

The final method is to examine the performance 
reports supplied by subscribers themselves. The 


Table! 


Comparison of 
MSC—CSN Interface Performance Data 
before and after programming changes 


at ROMNEY | at BERWICK at MT. AUKUM —— 
BEFORE AFTER XCHANGE BEFORE AFTER XCHANGE BEFORE AFTER A CHANGE 
Daily Input 2475 4281 +730 2371 3198 +349 1000 1526 +526 
* Peak Hour 
$ input 411 776 4888 358 567 +584 176 272 +545 
É Daily Output __1486 2652 +789 1644 2585 +572 794 1296 1632 
у Peak Hour 
Output 244 402 4648 417 485 +163 140 200 3429 
Busy Trunk y: Puy 
(0827) 219 85 -612 384 148 -615 _ 681 261 -617 
+ Busy Station 
(0825) 1184 660 -443 3799 394 -896 160 140 -913 
5 Simulated Busy 
у Trunks (SBZ) — — 262 — = æ = — m — 


Social Security subscribers who constitute about 
40 percent of the total subscriber population, pub- 
lish daily reports containing performance figures 
of merit for the traffic sent to the MSCs. These 
figures of merit are, in essence, ratios of incom- 
pleted calls to completed calls. These daily re- 
ports indicated that the programming changes had 


cut these ratios in half. 


Summary 

The programming modifications described above 
have given the MSC the necessary logic and data 
to recognize the size of the CSN and to operate 
efficiently using its share of the CSN. The per- 
formance improvements that resulted and the 
application of this approach to systems with simi- 
lar problems depend on two considerations. The 
MSCs handle fifty percent of the traffic and conse- 
quently, а significant increase in MSC to CSN 
operating efficiency has a measurable effect on 
overall system performance. Also the relatively 
limited size and the simple organizational struc- 
ture of the CSN lend themselves to the type of 
technique implemented. 
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The future work in the MSC to CSN interface 
will fall into two categories. The limits selected 
are conservative and, as more system performance 
data becomes available, further refinements will 
be made. In addition the picture of the CSN which 
has been programmed into the MSC is a static one 
representing the best interpretation of system be- 
havior at the time the programming changes were 
made. Should the CSN equipment configuration 
change or the traffic pattern shift, changes will be 
necessary in order to keep this picture up to date. 
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IMPROVED TRUNK ALLOCATION 
IN A CONGESTED NETWORK 


J. C. PARR 
and 
A. M. EISNER 


The primary purpose of a circuit switched network is to provide circuit switched 
communication paths for real time exchange of traffic between its subscribers. 
When a circuit switching network is also required to provide communications 
paths for store and forward traffic, the classic problem of allocating the limited. 
Common control equipment and facilities between this traffic and the real time 
circuit switched traffic occurs. In many cases this allocation problem is avoided 
by procedurally scheduling the delivery of store and forward trafic during non. 
peak traffic hours on the rationale that speed of service for this traffic is not 
critical. However, the store and forward traffic in ARS must be serviced during 


peak traffic hours along with the real time circuit switched trafic. The ARS solution. 
to the resultant allocation problem is to permit the circuit switching network to 


switch on the amount of common control equipment and facil 
message switch can use in delivering its trafic. In the case of the 
trunks in a trunk bundle this regulation is performed by limiting the message 
switch to a certain fixed maximum number of trunks in the trunk bundle. An 
improved design has been implemented which makes it possible to allocate the 
trunks within trunk bundles on a real time dynamic basis as a function of both 
the store and forward traffic and the real time circuit switched traffic load on the 
trunk bundle by placing the appropriate decision making control in the message 
switch. 


The Advanced Record System is composed of 
a Circuit Switching Network (CSN) and three dis- 
persed Message Switching Centers (MSCs). The 
CSN provides the basic service, real time point- 
to-point communication paths between the ARS 
subscribers. The MSCs provide the advanced serv- 
ices to these subscribers such as store and for- 
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ward handling, data collection and distribution, 
multiple address processing and message ex- 
change. Since these advanced services are re- 
quested by the subscribers and are provided by 
the MSCs using communication paths supplied by 
the CSN, the MSC is a CSN user. 


THE PROBLEM 


Both the MSCs and the subscribers use the 
CSN to provide communications paths for their 
traffic. As a result the CSN must handle an inter- 
mix of real time point-to-point circuit switched 
traffic, originating from the subscribers, and store- 
and-forward traffic originating from the MSCs. The 
CSN services requests for communications paths 
in the order of their appearance and, in allocating 
its limited common control equipment and faci 
ties, it makes no distinction between store-and- 
forward traffic and real time circuit switched traffic. 
In effect, the CSN allocates its common control 
‘equipment and facilities on а "first come, first 
serve” basis. However, the MSC controls this 
traffic intermix since it is the source of the store- 
and-forward traffic. This control is accomplished by 
limiting MSC usage of CSN common control equip- 
ment and facilities to predetermined maximum 
limits’, 

Two sets of limits are provided, one for peak 
hour MSC operation and one for non-peak hour 
MSC operation. These limits are imposed on 
MSC traffic to accomplish two objectives: 1) to 
prevent the MSC from using more than its fair 
share of the CSN common control equipment and 
facilities and thereby lowering the service provided 
to the subscribers, and 2) to minimize the use of 
common control equipment and facilities by the 
MSC in unsuccessful attempts to transmit its traf- 
fic. While the concept of predetermined fixed maxi- 
mum limits on MSC usage of CSN common control 
equipment and facilities meets the first objective 
traffic situations can arise where controls based on 
static limits do not satisfy the second objective. 
The special traffic situations arise, whenever trunk 
bundles in the CSN become saturated with traffic, 
and the MSCs can still request trunks in these sat- 
urated bundles without exceeding their pro- 
grammed trunk limits. 


STATIC TRUNK ALLOCATION 

The concept of controlling the CSN traffic inter- 
mix on CSN trunk bundles using fixed maximum 
limits in the MSC can be best described using the 
simplified ARS network shown in Figure 1. This 
simplified diagram was generated by selecting a 
limited part of the ARS network and proportionally 
reducing the number of trunks between the three 
major system components: the MSC, the CSN 
Junction Office (20) and the CSN District Office 
(DO). The selection and trunk reduction used to 
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create the simplified network was done such that 
any conclusions reached in examining traffic flow 
through the simplified network are also true in the 
actual ARS network. 

The trunks from the two JOs, JO, and JO; to the 
DO are of particular interest. The three trunks 
from JO, to the DO constitute a trunk bundle, and 
are labeled primary routes, since traffic originating 
from the MSC for subscribers on this DO would 
use trunks in this trunk bundle as a first choice 
path. If all trunks in the prime or first choice 
trunk bundle are busy, the trunk bundle is satu- 
rated; consequently traffic originating from the 
MSC must use alternate routes. In the simplified 
network the two trunks from JO; to the DO consti- 
tute another trunk bundle and provide possible 
alternate routes to the subscribers on the DO. If 
all trunks in both the prime route trunk bundle 
and the alternate route trunk bundle are busy, 
then trunk saturation has occurred for that DO. 

The fixed trunk limits programmed into the 
MSCs apply directly to MSC usage of these JO to 
DO trunks. The number of simultaneous calls, 


7 


which an MSC can make to subscribers on а раг- 
ticular DO during peak traffic hours, is limited to 
the maximum number of trunks in the prime route 
trunk bundle. In Figure 1, the MSC is limited to 
three simultaneous calls to subscribers on the DO 
during peak traffic hours. The three calls can take 
place over any of the five possible routes (JO 
to DO trunks) since the decision to go prime 
or alternate route is under the control of JO;. The 
two remaining trunks are available for real time 
point-to-point circuit switched traffic. During non- 
peak traffic hours the number of simultaneous 
calls from the MSC to subscribers on the DO is 
limited to a maximum value, equivalent to the 
total number of trunks in both the prime route 
trunk bundle and the alternate route trunk bundle. 
In Figure 1, the simplified network diagram, the 
MSC is limited to five simultaneous calls to sub- 
scribers on the DO during non-peak traffic hours. 
In this case no trunks are left for real time point- 
to-point circuit switched traffic, under the assump- 
tion that this traffic is negligible during non-peak 
traffic hours. 


Program Control 

Program control of the usage of JO to DO trunks 
is accomplished by means of a District Office Table 
(DOTAB). DOTAB contains 24 entries, one for each 
DO in the CSN. Each DOTAB entry contains the 
dial digits which uniquely identify the DO, 
counter which records the number of calls in 
progress (and therefore the number of JO to DO 
trunks in use) from the MSC to subscribers on the 
DO and two maximum limits, one for peak hour 
operation and one for non-peak hour operation. 
Each time the MSC is required to deliver a message 
to a subscriber the status of the DOTAB entry for 
the DO serving that subscriber is checked. In this. 
check, the MSC verifies that the number of calls 
in progress to subscribers on the DO, as specified 
in the counter, is less than the maximum value 
permitted before attempting to make the call over 
the CSN to the subscriber. The choice of the 
peak hour maximum value or the non-peak hour 
maximum value for use in this check is automatic- 
ally made by the MSC as а function of the setting 
of a console skip switch which is under the control 
of the MSC operator. In the event that the number 
of calls in progress to subscribers on the DO is 
more than the maximum permitted, the MSC does 
not attempt to make the call over the CSN to the 
subscriber. The call has encountered а simulated 


busy trunk condition, a busy trunk by program 
decision, and is placed in the MSC busy table in 
the same manner as a real busy trunk; that is, a 
busy trunk which would be encountered after dial- 
ing. The significant difference is that the simulated 
busy trunk condition is internal to the MSC and 
does not use any CSN common control equipment 
and facilities. The advantage of this program con- 
trol can be seen from the following example. 


Example 1—An Ideal Traffic Situation 

Suppose that the following traffic conditions 
exists in the simplified network, in Figure 1, during 
a peak traffic hour. Two trunks to the DO are oc- 
cupied with real time circuit switched traffic from 
two subscribers on the DO to two subscribers on 
‘other DOs not shown on the network diagram. One 
‘occupied trunk belongs to the prime route trunk 
bundle and the other is in the 
trunk bundle. The MSC, which is limited to a 
maximum of three calls to subscribers on the DO 
(the peak hour limit is equivalent to the number of 
trunks in the prime route bundle), is not trans- 
miting any messages to the CSN but six messages 
requiring delivery to subscribers on the DO have 
been received by the MSC. 

Under these conditions the MSC will assign the 
six messages to the six output areas associated 
with the six trunks from the MSC to JO}. Since no 
trunks to the DO are in use in DOTAB, the MSC 
will process the first call by transmitting the di 
digits of the called subscriber to ЈО». JO, will 
tend the call to the DO and ultimately to the called 
subscriber by using one of the two trunks remain- 
ing in the prime route trunk bundle. The MSC now 
has one trunk in use to the DO. Since the MSC is 
permitted, by program control, to use up to three 
trunks to the DO, the MSC will process the second 
call by transmitting the dial digits of this called 
subscriber to JO,. JO, will extend the call to the 
DO and ultimately to the called subscriber by using 
the remaining trunk in the prime route trunk 
bundle. At this point, the MSC has two trunks in 
use to the DO. Since the upper limit is three calls 
to subscribers on the DO, the MSC will place a 
third call by sending the called subscriber's dial 
digits to JOs. Since the prime route trunk bundle 
is saturated, JO, extends the call through JO, to 
‘the DO and finally to the called subscriber by using 
the second and last trunk in the alternate route 
trunk bundle. At this point all trunks to the DO 
are in use and any further attempted calls to sub- 


scribers on the DO from the MSC or from a sub- 
scriber will be aborted (terminated prematurely) 
with a busy trunk response. 

However, the MSC has reached its program 
limit for calls to the subscribers on the DO and 
will not attempt to place any of the three remaining 
calls to the subscribers on the DO. These three 
calls will be aborted for simulated busy trunk 
conditions and placed in the MSC busy table, 
where they are held for a fixed time period before 
transmission attempts are made. The program de- 
cision to abort these calls, due to simulated busy 
trunk conditions, is completely internal to the 
MSC and no common control equipments or facil- 
ities in the CSN are used. 

This example demonstrates a situation where 
both objectives in the control of MSC trunk usage 
are satisfied. First, the MSC is limited to its share 
of the JO to DO trunks (three) and is not permitted 
to lower the service provided to the subscribers 
(two calls). Second, the MSC does not use CSN 
common control equipment and facilities in un- 
‘Successful attempts to transmit its traffic (three 
calls are aborted internally). 

However, in a less than ideal traffic situation, 
control of MSC trunk usage based on static or 
fixed limits will give less than ideal results as the 
following example demonstrates. 


Example 2—A Congested Traffic Situation 
Suppose that the following traffic conditions 
exist in the simplified network during a peak traf- 
fic hour, Three trunks to the DO, one in the prime 
route trunk bundle and two in the alternate route 
trunk bundle, are occupied with real time circuit 
switched traffic from three subscribers on the DO 
to three subscribers on other DOs not shown on 
the network diagram in Figure 1. Three of the 
trunks from the MSC to JO, are occupied with 
store-and-forward traffic from the MSC to three 
subscribers on DOs not shown on the network 
diagram. The remaining three trunks from the 
MSC to JO; are available and the MSC, which is 
limited to а maximum of three calls to subscribers 
on the DO of interest, has received six messages 
requiring delivery to subscribers on that DO. 

In this situation the MSC will assign three of 
the six messages, for the subscribers on the DO, 
to the output areas associated with the three re- 
maining trunks from the MSC to JO,. The remain- 
ing three messages for subscribers on the DO 
must wait until output areas and trunks to JO; 


become available. Since the DO entry in DOTAB 
indicates that no trunks are in use by the MSC to 
the DO, the MSC processes the first call to a 
scriber on the DO by transmitting the 
of the called subscriber to JO,. JO, extends the 
call to the DO and ultimately to the called sub- 
scriber by using one of the two trunks remaining 
in the prime route trunk bundle. The MSC now has 
one trunk to the DO in use and is permitted, 
accordance with its program limit for the DO, to 
process а second call through JO;. JO, extends 
this call to the DO and ultimately to the called 
subscriber by using the last trunk in the prime 
route trunk bundle. All trunks to the DO are now 
‘occupied. The MSC has two calls in progress to 
subscribers on the DO, has one call for a sub- 
scriber on the DO in an output area which can be 
sent to the CSN without violating the program 
trunk limit for the DO, and has three calls for 
subscribers on the DO awaiting assignment to 
output areas and trunks to JO,. 

Since DOTAB indicates that, for this DO, the 
number of trunks in use (two) is less than the peak 
hour maximum allowed (three), the MSC processes 
the third call to the subscriber on the DO by trans- 
miting the dial digits of the called subscriber to 
30. JO, cannot directly extend the call to the DO, 
since all prime route trunks to the DO are occu- 
pied; therefore it extends the call through an alter- 
nate route to JO,. JO; cannot extend the call to the 
DO since all alternate route trunks to the DO are 
‘occupied and returns a busy trunk signal to JO, 
and ultimately to the MSC. The MSC aborts the 
attempted call, places it in the MSC busy table and 
releases the output area and trunk toJO assigned 
to the aborted call. The MSC immediately assigns 
the fourth call to the newly available output area 
and trunk to JO}. Since only two calls are in prog- 
ress to subscribers on the DO, the MSC is per- 
mitted, without exceeding its DO trunk limit, to 
process the fourth call to a subscriber on the DO. 
This call follows the same path through JO, to JO, 
as the third call where it is also terminated with a 
busy trunk signal returned to the MSC. The MSC 
aborts the fourth call, places it in the MSC busy 
table and releases the output area and trunk to 
JO, assigned to the aborted call. The process is 
repeated in the same fashion for the fifth and sixth 
calls to subscribers on the DO. Ultimately all six 
calls have been attempted with two calls com- 
pleted and four calls terminated due to busy trunk 
responses from the CSN. 


In this case the program control of MSC usage 
of JO to DO trunks is not effective. This is demon- 
strated by the fact that the handling of the six 
calls from the MSC to the subscribers on the DO 
in this example is the same, regardless of whether 
‘or not the MSC operates in accordance with trunk 
limits. The first objective of trunk control is sati 
fied since the MSC is limited to its share of the 
JO to DO trunks (actually less than its share) but 
this is due to the traffic environment not the pro- 
gram control of MSC trunk usage. The second ob- 
jective of trunk control is not met since four of 
‘the six calls from the MSC to subscribers on the 
DO were attempted using CSN common control 
‘equipment and facilities and were aborted due to 
busy trunk responses from the CSN. 

The MSC delivery requirements to subscribers 
‘on the DO and the MSC program limit for the traf- 
fic to subscribers on the DO are the same in this 
second example as they were in the first example 
for ideal traffic. The difference between the two 
‘examples lies in the traffic environment which ex- 
ists in the network when the MSC is required to 
make the six deliveries. Several conclusions can 
be reached based on the results of these two e 
amples. First, MSC program control based on fixed 
trunk limits is completely effective when the CSN 
can supply the number of JO to DO trunks neces- 
sary to handle the number of calls permitted by 
the program trunk limit. The ideal traffic example 
demonstrates the effectiveness of program control 
for this case. Three of the six calls from the MSC 
to subscribers on the DO were transmitted suc- 
‘cessfully and three were processed internally with. 
out using CSN common control equipment and 
facilities. Second, MSC program control based on 
fixed trunk limits is partially effective when the 
number of output trunks available from the MSC 
to its collocated JO exceeds the number of calls. 
permitted by the program trunk limit. If all six 
trunks from the MSC to JO, were available in the 
congested traffic example, the handling of the six 
calis from the MSC to subscribers on the DO would 
have resulted in two completed calls, one call ter- 
minated due to a real busy trunk condition and 
three calls terminated internally in the MSC due 
to simulated busy trunk conditions. Finally, MSC 
program control, based on fixed trunk limits, i 
ineffective when the number of output trunks avail- 
able from the MSC to its collocated JO is equal to 
or less than the number of calls permitted by the 
program trunk limit; and when the CSN cannot 
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supply the number of JO to DO trunks necessary 
to handle the number of calls which the MSC can 
attempt to transmit over its output trunks. The 
congested traffic example demonstrates this prob- 
lem. The number of output trunks available from 
the MSC to JO, (three) equals the number of calls 
specified by the program trunk limit and the num- 
ber of JO to DO trunks which the CSN can supply 
(two) is less than the number of calls which the 
MSC can attempt to transmit over its output trunks 
(three). 

The primary problem with program control using 
fixed trunk limits is that the MSC processes its 
traffic for subscribers on a DO based only on an 
evaluation of the amount of MSC store and forward 
traffic to subscribers on the DO and neglects infor- 
mation concerning the CSN real time traffic to and 
from subscribers on the DO. In order to consider 
the full traffic load in the DO, the MSC must do 
special processing whenever a busy trunk response 
is received from the CSN. 


DYNAMIC TRUNK ALLOCATION 

The special processing which the MSC must do, 
when a busy trunk signal is received from the CSN, 
is based on the interpretation of the meaning of a 
busy trunk signal, The receipt of a busy trunk 
signal at the MSC, for a call to a subscriber on a 
DO, is not just an indicator that the traffic to sub- 
scribers on the DO has reached a saturation con- 
dition. It also indicates, that the real time circuit 
switched traffic of the subscribers on this DO has 
reached a level which requires the use of trunks 
which the MSC is normally permitted to use. It 
also suggests that unsuccessful attempts are being 
made by subscribers to transmit real time circuit 
switched traffic to subscribers on the saturated 
DO. These unsuccessful attempts on the part of 
the subscribers and the MSC to transmit traffic to 
subscribers on the saturated DO can adversely 
affect CSN operation in other DOs by inefficient 
use of common control equipment in the JO. This 
congestion problem can be substantially reduced 
by controlling MSC traffic to subscribers on the 
DO, as a function of the CSN traffic load in the DO 
or, more specifically, as a function of busy trunk 
signals received from the CSN in attempting to 
transmit traffic to subscribers on the DO. 
Concept of a Lower Threshold 

‘The control of MSC traffic to subscribers on a 


DO as a function of busy trunk signals received 
from the CSN on calls to subscribers on the DO is 


based on the concept of a lower threshold, in addi- 
tion to the two upper thresholds already provided. 
This lower threshold specifies the maximum num- 
ber of calls which the MSC can place or attempt 
to place to subscribers on the DO regardless of 
the traffic situation in the DO. The upper thresh- 
olds (peak hour and non-peak hour) specify the 
maximum number of calls which the MSC can 
place to subscribers on the DO, provided that the 
traffic situation in the DO does not cause busy 
trunk signals to be returned from the CSN to the 
MSC. In effect, the lower threshold specifies the 
maximum traffic level from the MSC to subscribers 
on the DO, which the MSC is permitted to maintain 
in congested traffic situations; while the upper 
threshold specifies the maximum traffic level from 
the MSC to subscribers on the DO, which the MSC 
is permitted to attain in non-congested traffic 
situations. 

When the number of calls in progress, from the 
MSC to subscribers on the DO, lies between the 
lower and upper thresholds for the DO, MSC trunk 
usage will be controlled as a function of busy 
trunk signals received from the CSN. In this case 
a busy trunk signal will cause any additional MSC 
traffic to subscribers on the DO to be delayed re. 
gardless of the fact that the MSC is permitted, in 
accordance with the upper threshold, to transmit 
additional messages to subscribers on the DO. 
This delay will continue until one of the calls in 
progress from the MSC to a subscriber on the DO 
terminates. During this delay which varies as a 
function of MSC traffic to subscribers on the DO, 
any new traffic from the MSC to subscribers on the 
DO is terminated internally in the MSC due to 
simulated busy trunk conditions. Depending on 
the amount of traffic awaiting delivery from the 
MSC to subscribers on the DO and the number of 
‘output trunks available from the MSC to its collo- 
cated JO, this procedure can significantly lower 
unnecessary and inefficient use of CSN common 
control equipment and facilities. This “wait one 
message" philosophy is used in terminating the 
delay of MSC traffic to subscribers on the DO 
because it permits the MSC to terminate its delay 
at the earliest point at which JO to DO trunk avail- 
ability has been recognized in the MSC. At this 
point the MSC is permitted to place as many calls 
to subscribers on the DO as its upper threshold 
permits, provided that a busy trunk signal is not 
received from the CSN in attempting to place one 
of these calls to a subscriber on the DO. In this 


case the MSC must check its lower threshold 
against the number of calls in progress to sub- 
scribers on the DO and decide whether or not a 
delay of traffic from the MSC to subscribers on 
the DO is required. 


Dynamic Trunk Control 

‘The process of trunk usage control in the MSC, 
under the rules described above, can be demon- 
strated using the Trunk Allocation Diagram, shown 
in Figure 2. At time to, during a peak hour, the 
number of calls in progress from the MSC to sub- 
scribes on a DO is four. The upper threshold 
for calls from the MSC to subscribers on this DO 
during the peak traffic hour is six and the lower 
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Figure 2—Trunk Allocation Diagram. 


threshold is three. At time to, the MSC begins proc- 
essing a large queue of messages requiring de- 
livery to subscribers on the DO. In attempting to 
place the fifth call to a subscriber on the DO, the 
MSC receives a busy trunk signal from the CSN. 
Since the number of calls in progress from the MSC 
to subscribers on the DO is between the upper 
and lower threshold, the MSC must wait until one 
of its four calls to a subscriber on the DO termi- 
nates. Any calls processed by the MSC for sub- 
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scribers on the DO during the delay period are 
terminated due to simulated busy trunk conditions 
and placed directly in the MSC busy table. When 
one of the MSC calls to a subscriber on the DO 
terminates at time ty, the MSC attempts to place 
а fourth call to a subscriber on the DO (only three 
calls are now in progress). The MSC receives an- 
other busy trunk from the CSN and must again 
delay its traffic for subscribers on the DO since 
the number of calls in progress (three) is between 
the two threshold values. The receipt of а busy 
trunk in this case indicates that the JO to DO 
trunk, released when the MSC call to a subscriber 
‘on the DO terminated at time t,, was assigned by 
the CSN to a real time, circuit switched call to or 
from а subscriber on the DO. When one of the 
three calls now in progress from the MSC to a 
subscriber on the DO terminates at time ts, the 
number of calls from the MSC to subscribers on 
the DO is below the lower threshold and the MSC 
can attempt to place calls to subscribers on the 
DO regardless of busy trunk signals received from 
the CSN. At time t the MSC is successful in placing 
a third call to a subscriber оп the DO. At time t, 
the MSC places three calls in succession to sub- 
scribers on the DO. The first two of these calls 
are successful and the number of calls in progress 
increases to five. The third call results in a busy 
trunk signal from the CSN. This causes the MSC 
to delay its traffic for subscribers on the DO until 
one of the five calls in progress from the MSC to 
а subscriber on the DO terminates. At time t, one 
of these calls terminates and at time t, the MSC 
successfully places a fifth call to a subscri 
the DO. Finally, at time t the MSC places a sixth 
call to a subscriber on the DO. MSC traffic to sub- 
scribers on the DO has reached the upper thresh- 
old of six and no further attempts can be made 
by the MSC to place calls to subscribers on the DO 
‘until one of the calls in progress terminates. 

In effect this control permits the MSC to adjust 
its traffic to subscribers on a DO in accordance 
with the overall traffic load in the DO, not just 
according to the MSC originated traffic load in the 
DO. The traffic delay inherent in this control is 

inimized by requiring the MSC to wait only if 
the number of calls in progress to subscribers on 
the DO is equal to or greater than the lower thresh- 
old; and by requiring the MSC, in this case, to 
wait only until one of its calls in progress to a sub- 
scriber on the DO terminates. One other approach 
to controlling the delay can be used. This approach, 
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which can be termed “wait till threshold," results 
in less unnecessary use of CSN common control 
‘equipment and facilities but increased MSC delay. 
The "wait till threshold” approach requires the 
MSC to delay its traffic to subscribers on the DO 
for a busy trunk response from the CSN until the 
number of calls in progress is less than the lower 
‘threshold. In the example cited above, а "wait till 
threshold" approach would have eliminated the 
unnecessary use of CSN common control equip- 
ment and facilities that occurred at time t; but 
would have unnecessarily delayed MSC traffic for 
the busy trunk response at time t, The “wait опе" 
approach was selected over the "wait till thresh- 
old" approach because it minimizes delay without 
prohibitive use of CSN common contro! equipment 
and facilities. 


IMPLEMENTATION 
OF DYNAMIC TRUNK CONTROL 

The implementation of this dynamic trunk con- 
trol is based on a modification of the two-word 
DOTAB entry. The first word contains the dial 
digits unique to the DO and the counter which 
specifies the number of calls in progress (or trunks 
in use) and remains unchanged. The second word, 
which formerly contained only the peak hour maxi- 
mum trunk limit and the non-peak hour maximum 
trunk limit (the upper thresholds), has been modi- 
fied to include а control bit and a lower threshold 
in addition to the two upper thresholds. 

Whenever the MSC assigns а message to an out: 
put area and its associated trunk, it performs а 
series of checks before attempting to deliver the 
message to the CSN. One of those checks involves 
the use of DOTAB to verify that a JO to DO trunk 
is available (ог the call, This trunk check requires 
the MSC to verify that the number of calls in prog- 
ress to subscribers on the DO (as specified in the 
first word of the appropriate DOTAB entry) is less 
than the number allowed (as specified by the ap- 
propriate upper threshold in the second word 
of the DOTAB entry). If this check fails, the 
MSC sends the message to the MSC busy table 
without attempting to deliver the message to the 
CSN. Dynamic trunk control requires an additional 
check which must be made before the trunk check, 
This additional check is made on the control bit in 
the second word of the DOTAB entry. If this con- 
trol bit is set, the MSC is in the delay mode for 
traffic to subscribers on this DO and the message 
is sent to the MSC busy table without performing 


the trunk check and without attempting to deliver 
the message to the CSN. 

This control bit is set whenever a busy trunk 
signal is received from the CSN on an MSC call 
to a subscriber on a DO and the number of calls 
in progress from the MSC to subscribers on this 
DO lies between the lower and the upper threshold. 
This control bit is reset whenever a message trans- 
mission from the MSC to a subscriber on this DO 
is terminated. 

The actual values used for the lower thresholds 
in the various DOTAB entries have been arbitrarily 
selected as equal to half the number of trunks 
specified by the peak hour upper threshold. This 
arbitrary selection was necessary, since exact sys. 
tem performance data was not available at the time 
the dynamic trunk control modification was made. 


‘SUMMARY 

The dynamic trunk control modification permits 
the MSC to adjust its usage of JO to DO trunks as 
а function of the total traffic load in the DO. This 
adjustment minimizes the unnecessary use of CSN 
common control equipment and facilities at a time 
when efficient usage is most important, namely, 

— 


during periods of congestion. The resultant im- 
provement in overall system performance has an 
associated penalty, the delay of traffic from the 
MSC to subscribers on the DO, But this traffic de- 
lay is minimal since delay periods only occur in 
periods of network congestion and these delay pe- 
riods terminate as soon as the MSC releases a JO 
to DO trunk to the DO. 

The future work in this area will be primarily 
concerned with the adjustment of the lower thresh- 
olds and the upper thresholds based on system 
performance data. The lower thresholds are con- 
servative and, in addition, the use of a lower 
threshold could, under the proper performance 
conditions, permit an increase in the upper thresh- 
old to expand the range in which dynamic trunk 
control operates. 
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THRUPUT IMPROVEMENT in 
MESSAGE SWITCHED TRAFFIC 


J. С. PARR 
and 
A. M. EISNER 


The processing of multiple address and group code messages is a standard serv- 
ice offered by message switching systems. It permits a user to input a single 
message and obtain multiple deliveries. The multiplicity factor associated with 
this type of traffic can present thruput problems in message switching systems 
and quite often restrictions are placed on the number of deliveries that a sub- 
scriber can request in a single message. The problem of providing this service 
in ARS is even more severe than in most message switching systems. There are, 
effectively, no restrictions placed on the number of deliveries the ARS subscri 

n request. In addition the deliveries must be made by the message switch 
Using the circuit switching network and sharing th ble common control 
equipment and facilities with the subscribers. The severity of this problem in 
ARS was indicated by performance data taken on ARS operation. These dala 
indicate that the actual delivery time for multiple address traffic exceeded the 


theoretical delivery time by a factor as high as six. The adjustments. 
ion of the message switch effectively changed this factor to on 
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The Advanced Record System (ARS) is a nation 
wide telecommunications system composed of a 
Circuit Switching Network (CSN) and three dis 
persed Message Switching Centers (MSCs). The 
CSN offers the ARS subscribers the real time sub- 
scriber-to-subscriber communication paths avail 
able in conventional circuit switching systems. The 
MSCs offer the subscribers the special services 
normally found in message switching systems such 
as store and forward handling, data collection and 
distribution, message exchange, and multiple ad- 
dress processing. The availability, in ARS, of the 
services found in each of these communications 
disciplines is noteworthy but the unique feature in 
ARS is the manner in which these disciplines are 
integrated into a single system. 
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The CSN is the essential system element in ARS 
and provides the basic communication service. The 
CSN is composed of two basic types of circuit 
switching offices, the Junction Office (JO) and the 
District Office (00). The JO is the high level office 
in the two-level CSN hierarchy and is primarily re- 
sponsible for providing communication paths be- 
tween DOs. The DO is the low level office in the 
two-level CSN hierarchy and is primarily responsi- 
ble for interfacing the subscribers to the CSN. 
The CSN provides the circuit switched communi- 
cation paths between subscribers in a conven- 
tional manner. The subscriber's call is made 
through his DO, through the appropriate JO and 
finally, through the called subscriber's DO to the 
called subscriber. 


Unique Feature of ARS 

The uniqueness of ARS becomes apparent when 
MSC traffic flow is examined. There are no dedi 
‘cated trunks or circuits between the MSCs and the. 
subscribers, The three MSCs are collocated with 
and connected to the three JOs in the CSN. Sub- 
scribers use the special services offered by the 
MSCs by sending appropriately formated messages 
over the CSN to the MSCs. The MSCs provide the 
special services by performing the required proc- 
‘essing and transmitting messages over the CSN 
to the appropriate subscribers. 

In effect, the CSN is providing communications 
paths for two types of traffic: 1) the real time cir- 
cuit switched traffic originating from the sub- 
scribers, and 2) the store-and-forward traffic 
originating from the MSCs. The ability of the CSN 
to provide the communication paths for the traffic 
intermix is severely taxed when the MSC is required 
to provide multiple address processing. In many 
cases, traffic constriction results in the MSC be- 
‘cause the CSN is unable to provide the quantity of 
‘communications paths required for MSC multiple 
address traffic. This should not be interpreted as 
ап indication that the CSN is inadequate. The CSN 
is configured and equipped to handle a poisson dis- 
tributed traffic load. The traffic distribution which 
results, due to multiple address traffic, is not 
Poisson distributed and represents the abnormal 
system case. If the CSN were designed to meet 
this abnormal traffic situation, a grossly overde- 
signed CSN would result. 


MULTIPLE ADDRESS PROBLEM 

Messages sent to the MSC by subscribers must 
conform to the message format rules, as specified 
in JANAP 128 [B]*. JANAP format is a fixed-field 
format, specifically designed for automatic proc- 
essing by digital computer message switches. One 
of the fields defined by this format, the routing 
field, is used to specify the destination to which 
the message is to be delivered. The MSC will de- 
liver a message received from the subscriber, in 
accordance with the seven character routing indi 
cator, found in this routing field. This seven 
character routing indicator uniquely identifies the 
required destination. If only one routing indicator 
is specified in the routing field, only one delivery 
is required; and the message is termed a single 
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address message. If more than one routing indi 
cator is specified in the routing field, multiple de- 
liveries are req: ind the message is termed a 
multiple address message. The multiple address 
message is a traffic multiplier. This multiplicity 
factor can become quite high since there is no pro- 
gram restriction on the number of routing indica- 
tors permitted in the routing field. 

Group code processing is a special case of mul- 
tiple address processing. In this case, the sub- 
scriber specifies a group code or collective routing 
indicator in the routing field. The MSC recognizes. 
the routing indicator as a group code and delivers 
а copy of the message to every subscriber specified 
in the MSC group code tables for the given group 
code. An individual group code routing indicator is 
limited to 625 deliveries, but there is no program 
restriction on the number of group code routing 
indicators permitted in the routing field of a mes- 
sage. An example of an ARS group code message 
is the “all points Social Security” group code mes- 
sage. This message contains eleven group code 
routing indicators in the routing field and requires 
745 deliveries. In this case while only one message 
is received in the MSC, 745 messages must be 
transmitted by the MSC. 

The minimum theoretical time required to de- 
liver а multiple address or group code message 
can be computed by multiplying the number of 
required deliveries by the number of bits in the 
message and then dividing the result by the capac- 
ity of the output trunks in bits per second. The 
multiple address or group code message cannot 
be delivered in the theoretical time computed be- 
cause this computation does not consider over- 
head time in the MSC and also the fact that other 
messages are being delivered. However, test data 
taken on MSC performance indicated that the ac- 
tual time, required by the MSC to deliver a group 
code or a multiple address message, could exceed 
the theoretical time required by a factor as high 
as six. 

This difference between actual time and theoret- 
ical time was due primarily to two basic factors: 
‘equipment and facility availability in the CSN and 
program design criteria in the MSC and their in- 
teraction on each other, In effect, the processing 
of multiple address traffic in the MSC places un- 
realistic demands on the CSN; and when these de- 
mands are not satisfied, the MSC reacts such that 
delivery of the multiple address traffic is ineffi 
cient. This interaction can best be understood by 
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‘examining the manner in which the MSC program 
processed message transmissions to the CSN prior 
to the programming modifications described later 
in this article. 


Message Queueing 

The software in the MSC can be divided into 
three functions: input processing, message se- 
lection and output processing. The primary 
function of the input processing program is to 
Validate the incoming message, record it on the 
reference journal, place it in in-transit storage and 
queue it for message selection and output process- 
ing. The queueing function is to make an appro- 
priate entry, called a QTRA entry, in the message 
queue table. The message queue table is a list of 
the messages in storage that are awaiting selection 
and output processing. The QTRA entry is a two- 
word entry which contains the drum address of the 
first segment of the message in the in-transit stor- 
age, the core address of the next QTRA entry in the 
message queue table and a definition of the output 
equipment requirements of the message. The out- 
put equipment requirements define which output 
interface(s) of the nine possible output interfaces 
is required to deliver the message. The nine possi- 
ble output interfaces in the MSC are MSC2, MSC1 
(the other two MSCs), CSN8 (ASCII subscribers), 
СЭМ (Baudot subscribers), OIP (the Output Inter- 
cept Position), AU (the AUTODIN system), VA (the 
Veterans Administration data collection tape), 
Telex/TWX (the Telex and TWX systems), and SS 
(the Social Security data collection tape). The out- 
put equipment requirements are specified in the 
QTRA entry using the EQRQ (equipment req: 
ments) format. This format uses nine bits, one per 
output interface, to specify the equipment require- 
ments of the message. If an EQRQ bit is set in the 
QTRA entry, then the message has output equip- 
ment requirements for the output interface asso- 
ciated with that EQRQ bit. It should be noted that 
the terms equipment requirements and output. 
interfaces are interchangeable. 

In order to make a message available for selec- 
tion and output processing. the input processing 
programs must perform a twofold function. First, 
the input processing programs must analyze all 
routing indicators in the routing line in order to 
identify the output interfaces required for the mes- 
sage and set the corresponding EQRQ bits in the 
QTRA entry for the message. Second, the input 
processing programs must place the QTRA entry 
in the message queue table in accordance with the 
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message precedence and time of arrival. 

For example, in the case of the “all points Social 
Security" group code the input processing pro- 
grams will construct a QTRA entry with the MSC2, 
MSC1 and CSN8 EQRQ bits set. This is a reflection 
of the fact that all three MSCs participate in 
making the required 745 deliveries to the sub- 
scribers. The CSN8 EQRQ bit indicates that the 
MSC receiving the message has equipment require- 
ments for this message on its CSN output inter- 
face. The MSC2 and МӘСІ EQRQ bits indicate that 
the MSC receiving the message has equipment 
requirements for this message on its output inter- 
faces to the other two MSCs. However, the input 
processing programs have not identified which 
specific deliveries of the 745 required deliveries 
are to be handled over these three output inter- 
faces. This is a function performed by message 
selection. 

Message Selection 

The message selection programs examine the 
message queue table for each output interface, in 
turn, and select a message for a given interface 
based on the status of the EQRQ bit associated 
with that output interface in the QTRA entry for the 
message. If the EQRQ bit is not set, the message 
selection programs must examine the next QTRA 
entry in the queue table. If the EQRQ bit is set, 
the message has equipment requirements for the 
output interface being serviced and а message d 
livery must be scheduled over this output interface 

‘Since more than one delivery of a message may 
be required over a given interface, the message 
selection routines must specify which delivery is 
to be made by the output processing programs. 
The first time that a message is selected for any 
interface, the entire routing line is analyzed and 
a three-word Message Dial Header (MDH) is con- 
structed for each required delivery. Each MOH 
Contains information on subscriber status, the 
‘equipment requirements for the associated delivery 
EQRQ format and the drum address of the sub- 
scriber dial code. When the message selection 
programs select a message for processing over a 
given interface, an MDH for a specific delivery 
over this interface for this message is given to the 
output processing program. Selection finds an ap- 
propriate МОН for a given interface by examining 
the EQRQ bits in each MDH іп the string of MDHs 
constructed for the message. 

In the case of the “all points Social Security" 
group code message the message selection pro- 


grams will build a string of 745 MDHs. Since all 
deliveries will ultimately be made to ASCII sub- 
scribers, each MDH will contain the appropriate 
status information unique to the subscriber and 
will contain the drum address of the unique dial 
code to be used in delivering the message to the 
subscriber. The EQRQ format in each MDH will be 
опе of three types. The EQRQ format in an МОН, 
for a delivery over the CSNB interface at the MSC 
which originally received the message, will have 
only the CSN8 bit set. The EQRQ format in ап МОН 
for a delivery to one of the other MSCs will have 
the appropriate MSC bit set and, in addition, will 
have the CSN8 bit set. This indicates that the de- 
livery associated with the MDH is to be made to 
the specified MSC, where it will be delivered over 
that MSC's CSNB interface. 


Output Processing 

The primary responsibility of the output proc- 
essing programs is to perform the necessary inter- 
play and coordination to establish the transmission 
path, transmit a copy of the message as found in 
in-transit storage and record the completion of the 
delivery on the reference journal. In the case of a 
message delivery to a subscriber via the CSNS or 
CSNB interfaces, output processing and message 
selection are closely interrelated. 

Once а message has been selected by the mes- 
sage selection programs for either one of the CSN 
interfaces and one of its deliveries has been sched- 
uled for output over one of the MSC to CSN trunks, 
the delivery will be transmitted successfully or will 
be terminated due to an output error or trouble 
condition, A busy trunk or a busy station response 
from the CSN for a delivery attempted by the MSC 
are two examples of output errors or trouble con- 
ditions which will cause a delivery from the MSC 
to the CSN to be terminated. When an MSC de- 
livery to the CSN is terminated due to an output 
error or trouble condition, another attempt is made 
to deliver the message after a delay of 60 seconds. 
This delay is accomplished by making an entry for 
this message in the Subscriber Busy Table (SBT). 
Busy Table Operation 

‘The efficient operation of the MSC-to-CSN inter- 
face depends to a large extent on the SBT function. 
Stated simply, the SBT function makes the trans- 
mission retry of a message delivery occur after a 
fixed time delay regardless of the length of the 
message queue. The importance of this feature 
can be demonstrated by considering the case of a 


busy station response from the CSN for an at. 
‘tempted delivery. Analysis and theoretical compu- 
tations, using performance data taken on ARS 
operation, indicated that the expected waiting time, 
before а busy subscriber will terminate the con- 
nection and therefore be available for an MSC 
message delivery, is approximately 60 seconds. 
From a statistical point of view, therefore, the 
optimum time to retry a message delivery to the 
CSN, which has been previously terminated due to 
а busy station response, is 60 seconds after the 
terminated attempt. Without an SBT function it 
would be impossible to take advantage of this 
statistical property. 

The busy table is a circular table capable of 
holding 50 three-word entries. The first word of the 
entry, QTRADD, contains the core address of the 
QTRA entry in the message queue table associated 
with the message being placed in the busy table. 
The second word, EQRGP, contains, in EQRQ for- 
mat, the output interface over which the delivery 
was attempted and also contains a count of the 
number of extra cycles of 60 seconds each that the 
entry must make before leaving the busy table. In 
the case of a Telex or a TWX message entering the 
busy table, this count was set at three. For the 
CSN interfaces the count was set at zero. The third 
word, TWAIT, contains the time at which the entry 
is to be removed from the busy table. The use of 
TWAIT to specify the time that an entry is to be 
removed permits the MSC to implement the sta- 
tistical property associated with the busy station 
response, 

The control logic associated with the busy table 
performs four basic functions: 1) it builds or makes 
an entry in the table when required, 2) it main- 
tains the time scheduling necessary to remove the 
oldest entry in the table when its time delay has 
expired, 3) it removes an entry from the table when 
required, and finally, 4) it requeues the message 
for selection when the associated entry has left 
the table. Figure 1 shows the basic busy table 
functions and their interrelationships. 

The requirement to build an entry can arise from 
two sources. It can be caused by an output error 
occurring on an attempted message delivery or it 
can be caused by the requirement to reinsert an 
entry which has been removed and has a non-zero 
cycle count. If it is caused by an output error, it 
can cause the premature removal of the oldest 
entry if the table is full. In this case, the oldest 
entry is removed regardless of its time scheduling 
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Figure 1—Functional Block Diagram of the Busy Table Operation 


or its cycle count. The requirement to remove an 
entry can also arise from two sources. It can occur 
due to the time scheduling of the oldest entry or 
it can be caused by the requirement to add an 
entry to a full table. If it occurs due to time sched- 
uling, the cycle count is inspected. If the cycle 
count is not zero, the entry is placed back in the 
table using the build function. If the cycle count is 
zero, the message associated with the entry 
requeued, making it available to message selec 
tion. This is done by restoring the EQRQ bit in the 
ТАА entry associated with the output interface 
over which the message delivery encountered trou- 
ble. The fact that this EQRQ bit must be restored 
points out the critical problem in the operation 
of selection, CSN output processing and SBT 
processing. 


BASIC DESIGN LIMITATION 

While the concept and implementation of the 
Busy Table gave the MSC to CSN interface a crit- 
ical and necessary capability, the overall integra- 
tion of selection, CSN output processing and SBT 
processing had two significant drawbacks. First, 
‘any message which encountered an output error 
ог trouble condition, in one of its scheduled de- 
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liveries over an output interface and required SBT 
processing, could not be further selected as a me: 
sage candidate by the message selection programs 
for that output interface, until the suspended d 
livery left the busy table. In effect, one delivery 
encountering trouble on an output interface and 
entering the busy table suspended any new delivery 
attempts for this message over the given output 
interface. The output processing routines inhibited. 
further selection of this message and subsequent 
scheduling of its deliveries over the given output 
interface by setting the EQRQ bit associated with 
this output interface in the QTRA entry to zero. 
The primary reason for inhibiting selection for this 
condition was to prevent the selection of the MDH 
associated with the delivery being placed in the 
busy table. Since every bit in the MDH is already 
used and no bit has been dedicated to storing the 
status information that the delivery is in the busy 
table, the method of preventing а second selec- 
tion of the MDH was to prevent the selection of 
any MDH for that message for the given output 
interface. 

This design approach can significantly delay 
message deliveries in a group code or multiple ad- 
dress message. Most group codes require deliv- 


eries to only а few DOs in the CSN and the MSC 
group code tables are usually arranged in а non- 
optimum fashion with the deliveries ordered by 
DO. A typical group code message might have 75 
deliveries to three DOs arranged internally such 
that the first 25 deliveries are to the first DO, the 
second 25 deliveries are to the second DO and the 
final 25 deliveries are to the third DO. MDHs are 
built in the order in which the deliveries are spe- 
cified in the MSC group code table and MDHs are 
scanned for selection in the order in which they 
are built. This causes selection to schedule calls 
on every available output trunk to the same DO. 
The trunks from the JO to the DO become satu- 
rated and busy trunk signals are returned. Some 
MSC to CSN trunks begin message deliveries but 
others are released due to busy trunk conditions. 
No further deliveries of the message can be sched- 
uled over these idle MSC to CSN trunks since one 
of the previous deliveries required SBT processing. 
Deliveries to the second or third DO cannot be 
made even though no trunks to these DOs are in 
use by the MSC and the MSC has available output 
trunks to its collocated JO. 

This basic problem is illustrated in Figure 2. Se- 
lection finds message X and, upon examination of 


the MDH string, finds an appropriate delivery, de- 
livery Y, for the output interface being serviced. 
Delivery Y is attempted and the CSN responds with 
a busy trunk signal. Output processing removes the 
ЕАО bit associated with this output interface 
the QTRA entry for message X and SBT processing 
makes an entry for message X for the given output. 
interface. Delivery Z, which also requires output 
processing over that output interface, cannot be 
scheduled since the EQRQ bit in the QTRA entry 
for that output interface has been removed and 
selection cannot find message X when searching 
the message queue table for that output interface. 
The basic design goal of the programming change 
to be described later in this article can be stated 
with reference to this example. The scheduling of 
any delivery for output, e.g., delivery Z, should be 
independent of the status or outcome of any pre- 
viously attempted delivery of the message, e.g., 
delivery У. 


А Second Limitation 

The second drawback in the overall integration 
of selection, CSN output processing and SBT proc- 
essing is that all output errors on a given interface 
which require SBT processing place the message 
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Figure 2—Basic Design Problem 


in the busy table for the same amount of time. 
While this is not as serious as the first problem, 
the errors are different and should be handled dif- 
ferently. For example, a delay of 60 seconds, which 
is optimum for а busy station response, is not opti- 
mum for a busy trunk response. 


‘An Alternate Design Approach 

The basic problem in the processing of multiple 
address or group code messages is that a message 
delivery over a given output interface, which en- 
counters an error requiring SBT processing, causes 
the suspension of the selection of any other deliv- 
eries of the message over the given output inter- 
face. One solution is to suspend only the delivery 
which has encountered trouble and permit all other 
dei in the message for the given output 
interface to be selected and scheduled for output. 
This is a more efficient solution with respect to 
multiple address and group code handling, but is 
more likely to lead to the undesirable operation 
associated with a full busy table. When the busy 
table is full and a requirement arises to make an 
entry, the SBT routines will make the additional 
entry by prematurely removing the oldest entry. In 
effect, a problem delivery is placed in the busy 
table but at the penalty of prematurely releasing 
another potential problem delivery for selection. 
The dynamics of the busy table in the case where 
there are more than 50 deliveries which are en- 
countering trouble or error conditions and require 
SBT processing can lead to situations, where MSC 
processing time is very inefficiently used in making 
busy table entries and processing problem deliv- 
eries released as a result of making these entries. 
This full busy table condition can arise for large 
group codes if selection of message deliveries is 
permitted to continue as long as any deliveries re- 
main to be made. Therefore, one extreme—the 
original design, is inefficient with respect to out 
put processing but reasonable with respect to 
program operation and MSC time usage; and the 
other extreme—the alternate design, which is 
efficient with respect to output processing but can 
lead to situations where MSC time usage is exces- 
sive and inefficient. 

The alternate design approach is a tradeoff be- 
tween the two extremes described above in the fol- 
lowing sense. In general, when a message delivery 
over а given output interface encounters an error 
or trouble condition requiring SBT processing, only 
that delivery will be suspended. Other deliveries of 
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the message will be selected and scheduled for the 
given output interface. The exception to this gen- 
eral rule occurs when the occupancy (number of 
entries) in the busy table reaches a given thresh- 
old. In the event that a message delivery over a 
given output interface encounters а trouble condi- 
tion requiring а busy table entry and the busy 
table contains 35 or more entries, the EQRQ bit 
will be removed from the QTRA entry associated 
with the delivery. This suspends all further deliv 
eries of this message over the given output inter- 
face. This approach permits message selection, in 
most cases, to examine additional deliveries in a 
message for a given output interface even though 
а trouble condition has been encountered for one 
of the message deliveries over this output inter- 
face. It also minimizes the probability that a full 
busy table condition will be encountered, The 
choice of 35 as the threshold parameter is gov. 
етей by two considerations. It is high enough to 
permit message selection to search the group code 
deliveries in a message to a sufficient extent to 
keep the output trunks busy transmitting deliv- 
eries. It is low enough to minimize the probability 
of entering the full busy table mode of operation, 


The Implementation of the Tradeoff 

The problem which arises in attempting to im- 
plement this tradeoff solution is to make it com- 
patible with the basic message selection rules. 
The first time message selection finds a candidate 
message for a given output interface it will cause 
a string of MDHs to be built for the message. This 
string will contain a unique MDH for each delivery 
required in the message. The string will be scanned, 
‘on this first selection and on every subsequent se- 
lection of the message, to select a specific МОН 
for the given output interface. Three items of infor- 
mation are of particular interest in the MDH during 
this scan: the output interface required for the 
delivery; the "done" bit which, if set, indicates 
that the associated message delivery has been 
made; and the “in-transmission” bit which, if set, 
indicates that the associated message delivery has 
already been selected and is being transmitted. 
Each time message selection selects a given mes: 
sage for a given output interface, the string of 
MDHs is scanned and the first MDH found for the 
given output interface with neither its "done" bit 
nor its "'in-transmission"" bit set will be selected. 
Therefore, if the tradeoff solution described above 
implemented, message selection will reselect 


and reschedule the same message delivery which 
had encountered trouble over the given output 
interface. 


Busy Table Modifications 

To prevent this repeated selection and sched- 
uling of the same message delivery, some indicator 
must be used in the MDH to tell message selection 
that the message delivery is in the busy table and 
should not be selected. The indicator chosen is the 
“in-transmission” bit. This is the only available 
indicator in the MDH which can be used without 
drastically altering the basic structure of message 
selection. In effect the "'in-transmission" bit is 
given two meanings: the message delivery is in 
transmission or the message delivery is in the 
busy table, 

This programming change permits the message 
delivery rather than the message itself to be placed 
in the busy table. Since the "in-transmission" bit 
in the MDH is used to indicate that the message 
delivery is in the busy table, this bit must be turned 
off when the message delivery leaves the busy 
table. Therefore, the busy table entry must contain 
two additional words of information. The modified 
busy table entry is now a five-word entry instead of 
three. The first word, QTRADD, contains the core 
address of the QTRA entry for the message whose 
delivery is being placed in the busy table. The sec- 
‘ond word, MDHENT, is the first word of the MDH 
associated with the message delivery being sus- 
pended. It contains the subscriber status bits (i 
cluding the "done" bit and the "in-transmission"" 
bit) and, in EQRQ format, the output interface over 
which the message delivery was attempted. The 
third word, TWAIT, contains the time at which the 
entry is to be removed from the busy table. The 
fourth word, МОНАО, contains the drum address 
of the MDH associated with the message delivery 
being suspended. The fifth word, CNTRP, coni 
the number of extra cycles that the entry must 
make before exiting from the busy table. 

The two new words, MDHENT and MDHAD, are 
necessary in order to enable the SBT routines to 
turn off the “‘in-transmission” bit in the MDH 
thereby making it available to message selection. 
This process is done by writing the contents of 
MDHENT on the drum at the address specified by 
MDHAD at the time the delivery is removed from 
the busy table. 

А second major change made to the SBT pro- 
gramming routines was the reduction of the basic 


busy table time delay from 60 to 20 seconds. Using 
the basic busy table design described earlier this 
reduction permits entries to be made for any mul- 
tiple of 20 seconds as a function of the cycle count 
‘associated with the particular entry. The third ma- 
jor change made to the SBT routines was to make 
this cycle count, which specifies the number of 
extra cycles of 20 seconds that an entry must make 
before leaving the table, a function of the error or 
trouble condition requiring the busy table entry. 
Formerly, this cycle count was solely a function of 
the output interface over which the message deliv: 
ery was attempted. 

Table | lists the various output errors and де. 
fines the cycle counts and the total time spent in 
the busy table for each type of error condition. As 
indicated in Table I, the finer resolution in terms 
of the basic busy table cycle time permits a speci- 
fication of 20 seconds for a busy trunk error con- 
dition and a specification of 60 seconds for a busy 
station error condition, 

Table | also indicates that a group code mes- 
sage delivery encountering a simulated busy trunk 
error condition’ receives unique treatment. In this 
сазе the number of extra cycles in the busy table 
is a function of the length of the message. This 
special handling for group code message deliveries 
is based on the observation that simulated busy 
trunk error conditions encountered on group code 
message deliveries usually occur when most of the 
MSC output trunks and most of the JO to DO trunks 
handling MSC traffic are occupied with deliveries 
of the group code message. Under these condi- 
tions considerable trunk efficiency can be gained 
by processing the group code message as a func- 
tion of its length. 


Operator Control 

The basic program decision to inhibit selection 
of deliveries for a given message over a given inter- 
face is based on the busy table occupancy level. 
However, this program modification also provides. 
for MSC operator intervention and control through 
the use of a console skip switch. If this console 
skip switch is in the normal position, the pro- 
gram will inhibit further selection of deliveries of 
the given message over the given output interface 
if the busy table contains 35 or more entries. If 
this console skip switch is in the set position, 
the program will inhibit further selection of deliv- 
eries of the given message over the given output 
interface regardless of the number of entries in the 
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TABLE 1 • BUSY TABLE DELAY FOR VARIOUS TYPES OF OUTPUT ERROR 
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busy table. In effect, setting the console skip switch 
restores the selection rules to what they were prior 
to the program modification. The other improve 
ments, the reduction of the basic busy table cycle 
time and the use of the output error condition to 
determine the time in the busy table, remain in 
force. 

The reason for this operator control can be best 
explained by examining the handling of other mes- 
sages in the system when a group code message 
is being delivered. Under the old selection rules, 
selection of deliveries of the group code message 
was repeatedly suspended and restored as the 
group code message was being processed. During 
periods when the selection of the group code mes 
sage deliveries was suspended, other messages of 
the same or lower precedence were selected and 
delivered. Under the new selection rules the sus- 
pensions which permitted other messages to be 
serviced are almost non-existent and these other 
messages must wait until the group code message. 
has been delivered. In some cases this means a 
delay in excess of one hour. 

The console skip switch permits the MSC op- 
erator to invoke the old selection rules, if the 


n2 


group code message content and the number of 
messages waiting in queue behind the group code 
message justify such a procedure. 


ARS Performance Improvement 
Tested Successfully 

А number of tests have been run by the authors, 
shown in Fig. 3, using actual group code messages. 
with results which proved to be far better than 
those initially envisioned. All tests indicated si 
nificant system performance improvement. The 
group code messages are being processed in 
slightly more than the minimum theoretical time. 
Group code messages which formerly required 
more than six hours to deliver are being delivered 
im slightly more than one hour. In processing 
group code messages maximum possible use is 
being made of the output trunks from the MSC 
to the CSN. Group code deliveries which formerly 
used only half the available output trunks are 
using all output trunks. Selection of the deliveries 
of the group code message is never suspended 
as long as an active МОН is available for selection. 
Busy table occupancy is minimal under the new 
selection rules. In tests of the threshold and of the. 
full busy table mode of operation it was necessary 


Figure 3—J. С. Parr (left) and A. M. Eisner (right) 


to artificially lower the threshold to three and the 
table size to five. Finally, the error printouts asso. 
ciated with the delivery of a group code message 
have also decreased significantly. 


‘Summary 

This programming modification implements 
а simple concept. The processing of an errored 
message delivery should suspend that delivery 
only. Its implementation permits message selec: 
tion to continue the examination of message deliv. 
eries in multiple address and group code messages 
beyond the errored delivery. The MSC trunk and 
subscriber controls! effectively sort these addi 
tional message deliveries into two classes: those 
which have a high probability of successful deliv 
ery and should be attempted and those which have 
2 low probability of successful delivery and should 
be sent directly to the busy table. 

In effect this program change makes optimum 


in the Laboratory. 


use of the busy table and of the trunk and sub. 
scriber controls, to keep all output trunks busy 
with message deliveries and to drastically reduce 
the overall time required to deliver multiple ad 
dress and group code traffic 

The resulting improvement in performance was 
significantly enhanced by making the time delay 
in the busy table entry a function of the error or 
trouble condition encountered and, in the special 
case of a group code message delivery encounter: 
ing a simulated busy trunk trouble condition, by 
making the busy table time delay a function of the 
length of the group code message. 
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END-TO-END GRADE OF SERVICE 
|... THROUGH CIRCUIT SWITCHING 
NETWORK SIMULATION 


The design of a circuit switching network is primarily a trade-off between 
quantities of equipment provided and the customer service required for a defined 
traffic load. The parameter generally used in specifying service required by a 

| ‘customer or a subscriber is called “Grade of Service.” This parameter, expressed 
as a ratio of busy calls to calis attempted, is usually applied to components of 
a network such as trunk bundles and switching matrices rather than to the over: 
all network. In the Advanced Record System (ARS) the concept has been ex: 

| tended to include all the components in combination and is called End-to-End 
Grade of Service. 

End-to-End Grade of Service is not only a function of the circuit switching 
network with its multiple paths, alternate routes and complex switching rules 
but also a function of the origin and the destination of the traffic flowing through. 
the network. Manual computation of End-to-End Grade of Service for the various 
origin and destination types is very complex particularly when the objective is 
to measure the sensitivity of end-to-end grade of service to changes in the grade 
ot service in the various components of the system. A more practical approach 
to the computation of End-to-End Grade of Service is to simulate the circuit 
switching network by means of a computer model and to measure the End-to-End 
| Grade of Service which results, when this model is exercised. In the simulation 

of the ARS circuit switching network, the computer model used is based on the 
use of random numbers and is a Monte Carlo model. 


Theresa Sullivan 


The Advanced Record System is primarily a 


connects various District Offices and provides 
Circuit Switching Network (CSN) augmented by 


automatic alternate routing of traffic as required. 


three Message Switching Centers (MSC). The CSN 
is the basic system component in ARS in that it 
provides the communication paths for traffic from 
the ARS subscribers and from the three Message 
Switching Centers. The simplified diagram of the 
ARS network, shown in Figure 1, indicates that 
the CSN comprises two types of offices, higher 
level and lower level. The Junction Office (JO), the 
higher level office in the CSN hierarchy, performs 
the high level switching functions normally asso- 
ciated with а regional or tandem office. It inter- 
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In addition, the JO provides the interface between 
the MSCs and the CSN. The District Office (DO) 
is the lower level office in the CSN hierarchy: it 
performs the low level switching functions nor- 
mally associated with a local office. It provides the 
interface between the subscribers and the CSN 
and performs automatic alternate routing of traffic 
as required. 

Communication paths in the CSN are provided 
in а standard manner. A subscriber-to-subscriber 
call proceeds from the calling subscriber through 


the calling subscriber's DO, through an appropri- 
ate JO to the called subscriber's DO and ultimately 
to the called subscriber. In proceeding from the 
calling subscriber to the called subscriber, the 
call uses various units of common control equip- 
ment and facilities. It uses trunks in trunk bun 
dies between offices and matrix paths and other 
‘common office equipment, such as registers and 
path selectors in the offices. It will be assumed, 
in the following example, that the term matrix 
path includes the actual matrix as well as all 
pertinent common office equipment. In designing 
the CSN, these trunk bundles and matrices were 
selected so that а call entering any trunk bundle 
ог matrix is assigned а certain level or grade 
of service. This grade of service is expressed 
as а ratio of busy calls to calls attempted, and 
is usually applied to the various units of com- 
топ control equipment and facilities used, such 
as a matrix or a trunk bundle, Basically, grade of 
service for a trunk bundle or a matrix defines the 
probability of getting а busy call on that trunk 
bundle or matrix for an assumed traffic load. How- 
ever even if the grades of service associated with 
the various units of common control equipment 


and facilities are known, the problem of computing 
the end-to-end or subscriber-to-subscriber grade 
of service is formidable. This problem is compli- 
cated by two factors: 1) the choice of calling sub- 
scriber (origin) and called subscriber (destina. 
tion) can change and 2), the CSN can set up the 
required communication path in a number of ways. 
The following example demonstrates this problem. 


Problem: A Typical Subscriber-to-an-MSC Call 


A basic type of call made in ARS is a call from 
а subscriber to any MSC. A subscriber places a 
call to an MSC, using any one of four dial se- 
quences. Three of these dial sequences address 
the three unique MSCs, one dial sequence for each 
MSC. The fourth dial sequence is a common dial 
sequence and requests a connection to the “near 
est available” MSC. Most calls to the MSC are 
made using the common dial sequence since the 
probability of completing the call is increased 
and the MSC handling the call is immaterial, When 
а subscriber places а call to an MSC using the 
‘common dial sequence, the call is termed a "sub- 
scriber-to-any-MSC" call. 
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Figure 1—The ARS Network 
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Possible Paths 

In Figure 1, the Eastern subscriber Sı оп DO: 
places a call to any one of three MSCs. In this 
case any one of six different paths or routes may 
be used. The first path is from Sı to DO, through 
the DO: matrix to JO», via a trunk in trunk bundle 
#7 and through the JO; matrix to MSC1, ма a 
trunk in trunk bundle #1. The second path is 
from S, to 00, through the DO, matrix to JOy, 
via a trunk in trunk bundle #7, through the JO: 
matrix to JO: via a trunk in trunk bundle #5 and 
through the JO matrix to MSC3 via a trunk in 
trunk bundle #3. The third path is from S, to 
DO,, through the DO, matrix to JO, via a trunk 
in trunk bundle #7, through the JO: matrix to JO» 
via a trunk in trunk bundle #4, and through the 
JO: matrix to MSC2 via a trunk in trunk bundle 
#2. Paths 1, 2 or 3 represent the prime route out 
out of DO, and the prime secondary and tertiary 
routes, respectively, out of JO;. 

The fourth possible path permits a call from Sı 
to DO}, through the DO, matrix to JO, ма a trunk 
in trunk bundle #9, and through the JO; matrix 
to MSC2, via trunk bundle #2. The fifth path is 
from S, to DO, through the DO; matrix to JO, via 
a trunk in trunk bundle #9, through the JO; matrix 
to JO, via a trunk in trunk bundle #6 and through 
the JO, matrix to MSC3 ма a trunk in trunk bundle 
#3. The sixth path is from Sı to DO,, through the 
DO , matrix to JO, ма a trunk in trunk bundle #9, 
through the JO, matrix to JO; via a trunk in trunk 
bundle #4 and through the JO, matrix to MSC1 
ма a trunk in trunk bundle #1. Paths 4. 5 or 6 
represent the alternate route out of DO; and the 
prime secondary and tertiary routes, respectively, 
out of JOs 


Path Selection. 

The actual path chosen for a call from 5 to 
any MSC is determined by the originating DO 
and the first JO reached. When the call from Sı 
enters DOs, DO; will attempt to seize a prime route 
to JO», a trunk in trunk bundle #7. If a prime route 
trunk is available, DO: will attempt to build a path 
through its matrix between the input line from 
Sı and the output trunk to JO». If a DO: matrix 
path is available, the call is extended to JO, and 
JO. is responsible for the further extension of 
the call. If the DO; matrix blocks (that is no 
path is available) between the input line from Sı 
and the available output trunk to JO, then DOr 
will terminate the call with a busy signal. If all 
prime route trunks are busy, DO; will attempt to 
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seize an alternate route to JO», a trunk in trunk 
bundle #9. If an alternate route trunk is available, 
DO. will attempt to build a path through its matrix 
between the input trunk from Sı and the output 
trunk to JO». If a DO: matrix path is available, the 
call is extended to JO: and JO: is responsible for 
all further extension of the call. If the DO: matrix 
blocks between the input line from S; and the 
available output trunk ќо JO», DO: will terminate 
the call with a busy signal. If all alternate route 
trunks are busy, DO, has failed to extend the 
call to a high level office, a JO, and the call is 
terminated with a busy signal. 

In this first phase of "call extension," the DO 
makes the logical switching decisions. Any one of 
three possible results can occur: 1) The call can 
be extended to the prime JO, JO,, and enter the 
next phase, 2) It can be extended to the alternate 
JO, JO», and enter the next phase, and finally, 3) 
the call can be terminated when the DO is unable. 
to extend the call to either JO because of busy 
conditions. 


Prime Route Paths. 

In the second phase, the JO makes the logical 
switching decisions. М the call is extended to 
JO», the prime route JO, it will first attempt to 
extend the call to MSC1 using a prime route trunk 
trunk bundle #1 and an appropriate JO; matrix 
path. If а trunk in trunk bundle #1 and a JO 
matrix path are available, the call is completed 
to MSC1 over communication path 1. If the JO, 
matrix blocks, JO; will terminate the call with 
a busy signal. If all trunks in trunk bundle #1 
from JO; to MSCI are busy, JO: will attempt to 
extend the call to JO» using a secondary route 
trunk in trunk bundle #5 and an appropriate JO 
matrix path. If a trunk in trunk bundle #5 and 
JO; matrix path are available the call is extended 
to JO: and JO, is responsible for extending the 
call to an MSC. If the JO: matrix blocks, JO: will. 
terminate the call with a busy signal. If all second- 
ary route trunks to JO in trunk bundle #5 are 
busy, JO; will attempt to extend the call to JO: 
using a tertiary route trunk in trunk bundle #4 
and an appropriate JO; matrix path. If a trunk in 
trunk bundle #4 and a JO: matrix path are avail- 
able, the call is extended to JO: and JO: is re- 
sponsible for extending the call to an MSC. If 
the JO: matrix blocks or if all tertiary route trunks 

inate the call with a 


attempt to extend the call to MSC3 using a trunk 
in trunk bundle #3 and an appropriate JO: matrix 
path. If a trunk in bundle #3 and a JO» matrix path 
are available, the call is completed to MSC3 over 
communication path 2. If the JO; matrix blocks, 
JO» will terminate the call with a busy signal. If 
all trunks from JO; to MSC3 are busy, JOs 
return control to JO». In this case JO; will attempt 
to extend the call to JO». 

If the call is extended from JO, to JOs, JO; will 
attempt to extend the call to MSC2 using a trunk 
in trunk bundle #2 and an appropriate JO: matrix 
path. If a trunk in trunk bundle #2 and a JO: 
matrix path are available, the call is completed 
to MSC2 over communication path 3. If the JO; 
matrix blocks, JO: will terminate the call with 
а busy signal. If all trunks from JO; to MSC2 
ге busy, JO: will return control to JO; and ЈО, will. 
terminate the call with a busy signal. 

In this second phase of call extension, JO; 
makes the logical switching decisions and one of 
four possible results will occur: 1) The call can 
be completed over primary route to MSC; (com- 
munication path 1), or 2) over the secondary 
route to MSC3 (communication path 2), or 3) over 
the tertiary route to MSC2 (communication path 
3) or finally, 4) the call can be terminated due 
to busy conditions. 


Alternate Route Paths 

In the first phase of "call extension,” DO, can 
extend the call to JO: the alternate route JO. In 
this case, JO: handles the call extension in a man- 
ner analogous to that described above for JO. 
Again one of four possible results can occur: 1) 
The call can be completed over the primary route 
to MSC2 (communication path 4), or 2) over the 
secondary route to MSC3 (communication path 
5), or 3) over the tertiary route to MSC1 (сот- 
munication path 6) or finally, 4) the call can be 
terminated due to busy conditions. 

The "subscriberto-any-MSC" call is only one 
of a number of basic calls which can be made 
in ARS. However, the problem inherent in com- 
puting end-to-end grade of service in ARS can 
best be appreciated by developing a mathematical 
expression for grade of service for this type of 
call. 


Mathematical Expression 

A mathematica! expression for end-to-end 
grade of service for a "subscriber-to-any.MSC"" 
call can be developed using Figures 2 and 3. Fig- 
ure 2 is that part of Figure 1 which illustrates only 
а call from subscriber Sı to any MSC. This 
network, called network 1, is a series-parallel 
combination of links from node A, the entrance 
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Figure 2—ARS Network Path for a Subscriberto-any MSC Call 
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to the DO; matrix, to node J, the exit to any 
One of the three MSCs. The circuit from the 
subscriber Sı to DO. is not included since the 
grade of service on the subscriber circuit is zero 
(i.e. his circuit is always available). The various 
links in Figure 2 are identified as matrix paths 
ог inter office trunks using the key given on 
Figure 2. Associated with each link is a probability 
figure, р, which gives the probability of link avai 
ability, Link availability, р, and grade of service, 
9, are related by the simple formula: 


ре= 1 emn о 


Communication Path Availability 
The six communication paths described earlier 
for a call from S, to any MSC are composed of 
the links, shown in Figure 2 and are the only 
lid paths which can be used in this network. 
igure 3 defines these six communication paths 
in terms of the link notation used in Figure 2. 
It should be noted that there are a number of 


possible paths in the network of Figure 2, that 
are not included in Figure 3. These paths are not 
Possible valid paths and the design of the CSN 
prevents the use of these paths. The first three 
paths, as stated earlier, are prime routes with 
respect to DOs, The second three paths are alter- 
nate routes with respect to DOs. The mathematical 
expression for end-to-end grade of service, G, can 
be derived using Figure 3, and the following 
formula: 


[2] 


5 that the various. 
communication paths are available. The proba- 
lity that communication path 1 will be available 


P, = Pi Pa Ps Pa @) 


where р, p», ps and ps are the probabilities that 
each link in path 2 will be available. The probabil- 
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Figure 3—Type of Communication Path for а Subscriber to any 
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ity that communication path 2 will be available, 
if required, is: 


Ра = ру Pa Ps (1-Ps) Ps Ре Pr © 


where р, P». рь ps. pe. p» are the probabilities that 
each link in the path will be available and (1-р) 
is the probability that the link ЕЈ, in communica- 
tion path 1, is busy. The probability that com- 
munication path 3 will be available, if required, 
is: 


Ра = Pi Ра Ps n) (14 Px) PsPioPr (5) 


where Pi, Px P». Рь Ре n are the probabilities 
that each link in the path will be available and 
(1-p9 and (1-ps py) are the probabilities, respec- 
tively, that the link EG, in communication path 1 
is busy and that either the link EG, or the link 
HJ, (or both) in communication path 2 are busy. 
The link СН, and its associated probability, p. 
is not included since GH, is a matrix path. If СН, 
is not available (busy), the call would be termi- 
nated, and communication path 3 would not be 
examined. The probability that communication 
path 4 will be available, if required, is: 


P, = p po) Po Ри Pir © 


where р, рь Pw and py are the probabilities that 
each link in the path will be available and (1-p;) 
is the probability that link BC in communication 
path 1 is busy, The probability that communica- 
tion path 5 will be available, if required, is: 


Р, = р, (1р) Po Pro (Pu) Pis Pa Pi (7) 


where py, рь Pio: ра, Ри and p, аге the probabili- 
ties that each link in the path will be available 
and (1-p,) and (1-py) are the probabilities, respec- 
tively, that the link BC in communication path 
1 is busy and that the link FJ, in communication 
path 4 is busy. The probability that communica- 
tion path 6 will be available if required, is: 


Р, 


Ps (1-Ps) p» Pro (рь) Ps) Ри Ps Ра 

[] 
where pi. рь рь, Pie Ps and p, are the probabili- 
ties that each link in the path will be available 
and (1:22. (1-py) and (l-pu p) are the proba- 
bilities, respectively, that the link BC in com- 
munication path l is busy, that the link FJ, in 
communication path 4 is busy and that either 
tthe link Fl, or the link HJ, (or both) in communi- 
tation path 5 are busy. The link, IH, and its 


associated probability, Pu, is not included since 
1H, is a matrix path. If IH; is not available (busy), 
the call would be terminated and communication 
path 6 would not be examined. 

The probability that а call is completed in net- 
work 1 of Figure 2 is: 

E 

P= = 
End-to-End Grade of Service 

The end-to-end grade of service for a call from 
а subscriber to any MSC can be computed using 
equation (2) and is as follows: 


G= 1 — (ррар [Pa + (1р) Ps Po Pr + 
(1-99 (1-р. Pi) Ps Pro Ра] + Ps (Ро) 
Po Pro (ра + Ори) Pis Pis Pr + 
Сера) (аз p) Ри Pa PAD) 0) 
The computation problems associated with this. 
mathematical expression become apparent if the 
following calculations of interest are attempted: 
* Determine G given all pis 
* Determine the sensitivity of G to p, given all 
ps except p. 
• Determine some ps given G and the remain- 
ing ps 
These calculations indicate that more than a 
mathematical expression is required to solve the 
end-to-end grade of service problem. Some effi- 
cient and flexible method of handling all the vari- 
ables and their interrelationships is needed. 


Pa = Pit Pe Pst Pst Pot Po 
9) 


‘The Solution—The Monte Carlo Simulation 

In many cases where mathematical descriptions 
of physical systems are difficult to manipulate, it 
is possible to construct a model of the physical 
system and use this model to evaluate the per- 
formance of the physical system. In this case, the 
model is an analog of the physical system and 
the results which occur when this model is exer- 
cised are used to predict the performance of the 
physical system. This technique of evaluating or 
testing а physical system using a model of the 
system, is called simulation. When the model 
includes the concept of randomness or random 
processes, the technique is referred to as a Monte 
Carlo simulation. 


А Simple Example 
The concept of a Monte Carlo simulation, as it 


по 


applies to the End-to-End Grade of Service prob- 
lem, can be demonstrated by а simple example. 
‘Suppose, that it is necessary to determine the 
grade of service in the simple network shown in 
Figure 4. This network consists of two links, AB 
and BC, with origin A and destination C. Both 
links must be available in order to complete а call 
from A to C. The End-to-End Grade of Service is 
expressed as: 

6=1-Р=1- (P p) an 
where p, and p; are the probabilities, respectively, 
that links AB and BC are available. Once the ps 
are given, it is a relatively easy matter to compute 
G. For example, when both p, and p, are assigned 
the value of 0.5, P is equal to 0.25 and G is equal 
to 0.75. 


Figure 4—A Simple Network 


However, there is another approach to solving 
this problem which is highly significant to the 
computation of End-To-End Grade of Service in 
ARS. This approach is Monte Carlo simulation. 
‘Suppose that it were possible to generate a ran- 
dom variable for the availability or non-availability 
of link AB, such that AB would be available fifty 
percent of the time. In other words, in the long 
term average of a large number of random var- 
iables generated, AB would be available consistent 
with а value of p=0.5 even though any specific 
random variable generated would make AB avai 
able or not available. The toss of an unbiased coin 
would be a suitable random generator which 
meets these requirements. 
If the outcome of heads on the flip of the un- 
ised coin is equated to link available and the 
coin is flipped twice, once for link AB and once 
for link BC, a trial has been performed. If the 
result is heads, heads, the trial is a success, 
the call is completed. If not, the trial is a failure, 
i.e., one or both of the links are busy. A number 
of trials can be performed and the number of busy 
conditions divided by the number of trials gives 
an estimate of G. 

Table I, shown in Fig. 5, contains the results of 
50 tosses of an unbiased coin. These outcomes 
can be grouped into sets of two, and used to deter- 
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Figure 5—Matrix of Successful Trials Using an 
‘Unbiased Coin 


mine call success or failure. Table | indicates that 
7 out of 25 trials are successful since there are 7 
out of 25 sets of two heads (HH). This yields a 
P of 0.28 and a G of 0.72. This approximates the 
results calculated using equation (11) which yields 
a P of 0.25 and G of 0.75. 

In effect, the determinate problem, equation 
(11), has been replaced by a game of chance (the 
tossing of an unbiased coin) and the solution to 
the determinate problem by the results of pla 
the game of chance. This approach is called the 
Monte Carlo method.’ 


Simulation of a Subscriber-to-any-MSC Call 

The Monte Carlo method has its true value in 
dealing with a large number of variables. In the 
simulation of ARS, and the evaluation of end-to- 
end grade of service, the Monte Carlo method 
accommodates the greater number of variables 
without significantly increasing the amount of 
work required. 

Network 1, given in Figure 2, is basically the 
same type of network as the simple network. It 
has more than two links in any given path. How- 
ever, as in the simple network, each link in the 
path must be available in order for the call to be 
completed. It has a number of paths but the avail- 
ability of each path is determined in the same 
manner as that of the simple network. Therefore, 
in dealing with network 1 or any similar ARS net- 
work, the method used is identical to that used in 
the simple network. However, the particular rules 
and requirements governing choices of paths in 


the ARS network must be incorporated in the 
Monte Carlo simulation. 

In the ARS network, the link grades-of-service 
may theoretically range from 0.000 to 0.999. 
Therefore a random process that can deal with this 
range is needed. In effect, a random number 
generator capable of generating three digit random 
numbers is required. The random number gener- 
ated can be compared to the given link grade of 
service (probability of being unavailable 
busy). As a result of this comparison, a deter- 
mination of the availability or non-availability of a 
link can be made. If the random number is greater 
than or equal to the link grade of service, the link 
is available. If the random number is less than the 
link grade of service, the link is busy. When all 
links in a given path have been evaluated in terms 
of availability, a determination of the call success 
or failure can be made. If all links in a given path 
the call is successfully completed on 
this path. If one or more links in a given path are 


busy, the call cannot be completed on this path. 
If a matrix link іп any path is busy, the call is 
terminated due to busy conditions. If a call is 
completed on any path in the network, the call is 
a success. If a call cannot be completed on any 
path in the network, the call is terminated due to 
busy conditions. 

Table II contains а list of the links in network 
1, in the order of their appearance in Figure 3, 
where the six basic communication paths are de- 
fined. Associated with each link in Table 2 is the 
link grade of service and a random number. The 
random number is part of a set of random num- 
bers generated to perform a trial on network 1. 
The set of random numbers has been adjusted to 
yield results which illustrate the Monte Carlo 
method as applied to network 1. 

Using this set of random numbers an eval 
tion of link availability in path 1 shows that links 
AB, BC, and CE, are available and link EP, is 
busy. Therefore, path 1 is busy and the next al 


TABLE Il 
Test Data for NETWORK 1—SUBSCRIBER-TO-ANY MSC CALL 
Grade of Random 
Link Service® Numbers Communication Paths** 
1 2 3 4 5 6 
AB 1 356 x x x x x x 
BC 10 915 x x x 
СЕ, 1 478 x x x 
EJ, 10 qe [x 
EG, 10 614 x 
GH, 1 189 x 
нл 10 gee * 
ED 10 349 x 
DF, Т 935 x 
FA 10 524 x 
BD 10 923 x x x 
DF, 1 532 x x x 
FJa 10 146 x x x 
Fh 10 763 x 
IH 1 384 x 
Hs 10 767 x 
Fo 10 638 x 
СЕ, 1 271 x 
ЕЈ 10 907 x 


"Grade of Service Is expressed as the number of usys in 1000 tys. 


MAn X identifies a specifie fink 


i» member of the given communication path, 


Ir Тр sandom numbers are less than the link grade of service, and the comparison of these two values will result in a 


Tink busy 


nate path, path 2, must be examined. A compari- 
son of random numbers and link grades of service 
for links in this path indicates that links AB, BC, 
CE, and GH, are available and that link HJ, is 
busy. Therefore, path 2 is busy and the alternate 
path, path 3, must be examined. The random 
number and grade of service comparisons for the 
links in path З show that links AB, BC, СЕ, ED, 
DF, and FJ, are available. Therefore, path 3 is 
available and the call is successfully completed. 
I path З had been busy, no alternate path could 
have been tried and the call would have been 
terminated unsuccessfully due to busy conditions. 
Therefore, trial 1 of network 1 using the set of 
random numbers results in a successful call com. 
pletion through the network. 

Table 2 also indicates that the call could have 
been completed over path 4, 5 and 6 if link BC 
in the prime paths had not been available. 

If additional sets of random numbers are gen- 
erated and used to perform additional trials on 
network 1, an estimate of End-to-End Grade of 
Service for network 1 can be obtained by dividing 
the number of times the call is unsuccessful due to 
busy conditions by the number of trials. 


NETSIM 


The Monte Carlo approach described above has. 
been incorporated into a computer program called 
NETSIM (Network Simulation). This program has 
been designed for use on the Univac 418. NETSIM 
automatically simulates the placing of а given 
type of call in ARS and after a repeated number of 
trials computes the end-to-end grade of service 
associated with this type of call. NETSIM is pro- 
grammed to test trunk bundles and matrix paths 
in а manner identical to that used in the CSN. All 
Switching rules and alternate routing capabilities 
in the CSN are included in the NETSIM model. 
NETSIM is actually a collection of six network 
models each of which deals with а specific origin 
and destination associated with a specific type of 
CSN call. One of these models is network 1, а 
subscriber to any MSC call. These six models are 
as follows: 


1. Network 1—Subscriber to any MSC 
2. Network 2—Eastern Subscriber to Eastern 
Subscriber. 
Network 3—Subscriber to опе MSC 
Network 4—Any MSC to a Subscriber 
Network 5—Eastern Subscriber to Western 
‘Subscriber 
Network 6—Subscriber to two MSCs 
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‘These models can be illustrated by using Figure 
1. The first type deals with calls from a particular 
subscriber, S, to any MSC where the subscriber 
uses the common MSC dial code. The model for 
this call type is entitled "Network 1—Subscriber 
to Any MSC.” This model tests all links in a sub- 
scriber to any MSC call. These links include DO 
matrix paths, DO to JO trunk bundles, JO matrix 
paths, JO to JO trunk bundles and JO to MSC 
trunk bundles. 

‘The second type covers calls from subscriber to 
subscriber. The model for this call type is entitled 
"Network 2—Eastern Subscriber to Eastern Sub- 
scriber." This model simulates calls from а sub- 
scriber such as S, serviced by both JO, and JO; 
to another subscriber such as S, serviced by these 
305. This model tests all links in a subscriber to 
subscriber call and also covers а call from а 
western subscriber to a western subscriber, such 
as a call from subscriber 5, to subscriber Sy. 

The third basic call type handles calls from a 
particular subscriber such as 5; to a particular 
MSC such as MSC3 using the unique MSC dial 
sequence. The model for this call type is entitled 
"Network 3—Subscriber to One MSC” and re- 
quires that all links in a subscriber to one MSC 
call be tested. 

The fourth call type is a call from a particular 
MSC such as MSC2 to a subscriber serviced by 
both JO; and JO, such as 5,. The model for this. 
call type is entitled “Network 4—Any MSC to a 
Subscriber" and requires that all links be tested. 

The fifth call type deals with a call from an 
eastern subscriber such as S, to a western sub- 
scriber such as Ss. The model for this call type 
is entitled “Network 5—Eastern Subscriber to 
Western Subscriber". This model which requires 
that all links be tested also includes a call from a 
western subscriber to an eastern subscriber such 
as a call from subscriber-S, to subscriber Sj. 

The sixth call type covers calls from a sub- 
scriber such as S, to either of two MSCs such as 
MSC2 or MSC3 using the common MSC dial se- 
quence. The mode! for this call type is entitled 
“Network 6—Any Subscriber to Two MSC” and 
requires that all links be tested. 

Each of these models is a composite of those 
matrix paths and trunk bundles which can be used 
to establish а valid call path from the given origin 
to the given destination. 


Random Number Generation 

NETSIM uses the Monte Carlo method in ex- 
amining a network or model and arriving at а 
network grade of service for the type of call repre- 
sented by the model. The random numbers used 
by NETSIM to test the network model are provided 
by a random number generator. 

The multiplicative congruential method is used 
to generate random numbers to be used in a com- 
parison with the link grades of service. The ran- 
dom number generator algorithm *? used is: 


tni = (2+1) и, + 1 (modulo 2") (12) 


where u, is the random number generated on cycle 
n of the random number generator and шљ is the 
random number generated on cycle ..,. The ran- 
dom number generated on any given cycle is 
formed in accordance with equation 12 using the 
random number generated on the previous cycle. 
The initial value, и, is taken from the Univac 418 
incremental. real time clock, a value which is a 
variable. This algorithm is used modulo 2" in order 
to obtain a non-negative 18 bit word which can be 
compared to the grades of service which have been 
converted to 18 bit words. (The word size of the 
UNIVAC 418 is 18 bits.) 


Network 1 Model 

The basic element in a network model is the 
Network Link Table which contains the data neces- 
sary to form valid paths and determine call suc- 
cess or failure. This table contains a separate 
entry for each link in the network each time it 
appears as an alternate link in a different path. 
Each entry is composed of six words. The first 
‘word contains the link identification. The second 
word contains the link grade of service, i.e., the 
number of times this link is likely to be busy out 
of 1000 tries. The third word contains a pointer 
to the next link in this path provided the link being 
tested is available. If this word contains zero, the 
call has been completed successfully and the 
counter of successful calls must be incremented. 
The fourth word contains a pointer to the alternate 
link to be tried provided the link being tested 
busy. If this word contains zero, there is no al 
nate path. The call cannot be completed and the 
counter of busy calls must be incremented. The 
fifth word is used to maintain a count of the num- 
ber of times this link was available. The sixth word 
is used to maintain a count of the number of times 
this link was busy. 


Table Ill shows the Network Link Table for Net- 


TABLE Ш 
ANY SUBSCRIBER TO ANY MSC CALL—NETWORK 1 LINK TABLE 


Grade 

Link of 
Service. 

AB 1 


Call completed. 


Success Busy 
Counter — Counter Path No. 
1 
4 
з 
4 
5 
6 


E 


work 1—Subscriber to Any MSC. This link table 
contains twenty-five entries. When а call is simu- 
lated using Network 1, NETSIM tests AB, the first 
entry in the Network Link Table. If the comparison 
of the link grade of service and the generated 
random number shows that this link is available, 
the success counter for this link is incremented 
and NETSIM tests the next link in this path, BC. 
If AB is not available, the busy counter for this 
link is incremented. Since no alternate route exists 
(the next link pointer contains zero), the counter 
of busy calls is incremented and a new trial call 
is simulated on the network. 

NETSIM tests BC by comparing the grade of 
service of BC to a generated random number. If 
BC is available, its success counter is incremented 
and NETSIM tests the next link in this path, CE). 
If BC is not available, its busy counter is incre- 
mented and NETSIM tests the alternate route link, 
BD. 

NETSIM tests CE, using its grade of service and 
а generated random number. If CE, is available, 
its success counter is incremented and NETSIM 
tests the next link in this path, EJs. If CE, is not 
available, its busy counter is incremented. Since 
no alternate path exists, the counter of busy calls 
is incremented and another trial call is simulated 
on the network. 

NETSIM tests EJ, using its grade of service and 
a generated random number. If EJ; is available, 
its success counter is incremented and since the 
next link pointer contains zero, this call has been 
completed successfully via communication path 1. 
NETSIM increments the counter of successful calls 
and simulates another trial call on the network. If 
EJ, is not available, its busy counter is incre- 
mented and NETSIM tests the link, EG, of an 
alternate path. 

NETSIM tests the remaining communication 
paths, if necessary, in network 1 using the Net- 
work 1 Link Table shown in Table 2. The testing 
of these paths proceeds in exactly the same man- 
ner as described above for communication path 1. 


Sample Results 

When the NETSIM program is initiated, the 
operator specifies the data on which the program 
runs are to be made. This data includes the date 
of the run, the network number, the total number 
of calls to be tried on this network and the grade 
of service for each the network. The print- 
out which results at the completion of the pro- 
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gram run contains the operator specified data as 
well as the results of the program run. 

Figure 6 represents a typical printout at the end 
of a program run. The first line of the printout in 
Figure 6 contains the data on which this run was 
made. The second line contains the network num- 
ber and name. The following lines are a diagram 
of the network being simulated. Following the 
diagram is a list of four columns. The first column 
contains the identification of the link. The second 
column contains the particular link's grade of 
ie. the calculated number of times the 
link will fail out of 1,000 tries. The third column 
contains the number of times the given link was 
available. The fourth column contains the number 
of times the link was busy in the particular path 
being tested. For example, link AB has a proba 
bility of being busy once in a thousand times. It 
was available 9,993 times and busy 7 times in this 
program run. Link BC has a probability of being 
busy ten out of a thousand times. It was available 
9,879 times and busy 114 times. 

Following the results for each link, the printout 
specifies the number of calls which were success: 
fully completed. In this particular network run, the 
number of calls completed was 9,977. The next 
entry of the printout specifies the number of calls. 
which were terminated unsuccessfully due to busy 
conditions. In this particular network run, the 
number of calls which could not be completed was 
23. 

The following three entries contain the quantity 
of random numbers generated that lie within each 
of three prescribed ranges: 000 to 333, 334 to 
666 and 667 to 999. These three entries are 
printed out to maintain a simple check on the 
random numbers being generated. 

The results of the program run associated with 
the printout of Figure 6 indicate that P is equal 
to 0.9977 and that G is equal to 0.0023. In other 
words, the simulation model has determined that 
the grade of service for this particular call type is 
0.0023 or 23 busy responses in 10,000 calls at- 
tempted. Some care should be taken in inter- 
preting these results. They depend directly on the 
link grades of service specified in the simulation 
run. These link grades of service depend, in turn, 
оп the operating condition of the actual equip- 
ment. As an example, suppose that a trunk group 
is equipped with six trunks to provide a grade of 
service of 0.01 for the assumed traffic load. If one 
of these trunks is not operational due to equipment 


failure, the grade of service on the trunk group for 
the same assumed traffic load is greater than 0.04. 
The simulation model only predicts end-to-end 
grade of service based on link grade of service 
and can only provide an end-to-end grade of 
Service measurement in a network with equipment 
failures if the link grades of service in the network 
model have been appropriately adjusted to reflect 
the change in link grades of service due to these 
‘equipment failures. 

‘SUMMARY 

The NETSIM program is significant for two basic 
reasons. First, it provides an effective method of 
determining end-to-end grade of service in ARS. 
It permits the examination of six basic ARS call 
types and includes, in its six network models, the 
alternate routing capability and switching rules 
found in the CSN. Second, it uses a simple but 
effective simulation technique, the Monte Carlo 
method. 

‘Some comments must be made on the problems 
ineherent іп a Monte Carlo simulation. As in all 
simulations, the results are a function of the 
degree to which the model represents the actual 
system. The NETSIM model, by design and by 
results obtained, seems to be an excellent analog. 
of the CSN. The role of a random number 
tor is critical in a Monte Carlo simulation. The 
particular algorithm used in the NETSIM program 
has proved to be completely satisfactory. The final 
problem which is probably the most serious one in 
а Monte Carlo simulation involves the determina: 
tion of the number of repetitions or trials required 
in order to develop а dependable result. In the 
case of NETSIM it was found that a number of 
program runs (ten) with the number of repetitions 
in each run, an order of magnitude larger (10,000) 
than link grade of service accuracy gave consistent. 
and accurate results. The accuracy of these results 
was checked by manually computing end-to-end 
grade of service using mathematical equations. 

Despite these problems application of the Monte 
Carlo method should be investigated whenever a 
performance evaluation of a physical system, 
which behaves in accordance with probabilistic 
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